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See your proposed circuit or packet-switched network perform 

COMNET II.5 now gives you easy-to-understand network 
simulation results quickly-no programming 


W ith COMNET II.5 you 

simply describe your tele¬ 
communication network and its 
routing algorithms. 

Simulation follows immediately 
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You get an animated picture of 
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tion during the simulation are ap¬ 
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PRE-REGISTER FOR THE 
13th Conference on 
Local Computer Networks 

Conference Site - The Radisson Plaza Hotel 
35 South 7th Street 
Minneapolis, MN 55402 


Program Co-Chairs: 

Larry Green 
Protocol Engines, Inc. 

530 E. Montevito 
Suite 106 

Santa Barbara, CA 93103 
(805) 965-0825 

General Chair: 

Ron Rutledge/MS 6271 
Martin Marietta Energy Systems 
Oakridge National Laboratories 
Oakridge, TN 37831-6271 
(615) 576-7643 

Registration Information: 

Pre-registration must be received on or before Wednesday 
October 5, 1988 - no exceptions. We are not responsible 
for your delays, mail delays, etc. Registration fee for 
conference (Oct. 11-12) provides for conference 
proceedings, four refreshment breaks, two luncheons, and 
the banquet. Tutorial registration fee (Oct. 10) includes 
luncheon, tutorial notes, and two refreshment breaks. 
Make all checks payable to: 

Conference on Local Computer Networks 

Hotel: 

A number of rooms has been set aside at the Radisson 
Plaza Hotel Minneapolis, 35 South 7th St., Minneapolis, 
MN 55402; (612) 339-4900. Please reference 13th 
Conference on Local Computer Networks. 


Program Includes: 

Monday, October 10, 1988 

7:30 a.m. - 9:00 a.m. Registration 

9:00 a.m. - 5:00 p.m. Tutorial 1 

"TCP/IP: What does it do, and Why." Dan Lynch, 

Advanced Computing Environments 

9:00 a.m. - 5:00 p.m. Tutorial 2 

"Local Area Network Planning and Management," Tom 

Kieffer, Connect Computer Company 

Tuesday, October 11,1988 

8:00 a.m. - 9:30 a.m. Registration 

9:30 - 11:00 a.m. Keynote Session 

"Network Management," Eric E. Sumner, Vice President 

Operations Planning, AT&T Bell Laboratories 

10:45 a.m. - 12:15 p.m. Technical Program 

12:15 p.m. - 1:30 p.m. Lunch 

1:30 p.m. - 5:00 p.m. Technical Program 

5:30 p.m. - 6:30 p.m. Cocktail Party 

6:30 - 9:00 p.m. Banquet 

"USA Today, Tomorrow the World," International Touring 
Company of Dudley Riggs Brave New Workshop. 

Wednesday, October 12,1988 

8:30 a.m. -12:15 p.m. Technical Program 

12:15 p.m. - 1:30 p.m. Lunch 

1:30 p.m. - 5:00 p.m. Technical Program 


Robert Linebarger 
Computer Science Dept. 

242 TMCB 

Bringham Young University 
Provo, UT 84602 
(801) 378-2835 


|You are responsible for your own hotel reservations!! 


I Registration: 

I Send registration and fee to: 
13 th Conference on 


j Local Computer Networks 
Harvey A. Freeman 
| LANWORKS, Inc. 

| P.O. Box 506 
| Hopikins, MN 55343 


Students (include copy of ’88 
paid fee statement) 


IEEE Members 


Conference 

Tutorial 1 

Tutorial 2 

$100_ 

$145_ 

$145_ 

$200_ 

$145_ 

$145_ 

$250_ 

$185_ 

$185_ 

Payable in U.S. Dollars 



j Organization _ 

I Address & Zip _ 

— 

j Phone _ 

] Registrations received after October 5 will be returned without exception! Registration after October 5 will be handled 
on-site at the rate of $225 for the conference and $175 for the tutorials for IEEE members and $285 for the conference 
|and $220 for the tutorials for non-members. Register early! 
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The growth and vitality of our standards activities 



Edward A. Parrish, Jr. 


his month I have asked our vice 
president for standards to 
report on what has become a 
major activity for the Computer Soci¬ 
ety. In just a short time, our standards 
efforts have grown from humble begin¬ 
nings to the point where the society is a 
major participant in establishing impor¬ 
tant hardware and software standards 
that benefit the entire industry. 

Edward A. Parrish, Jr. 

President 


“Vitality” is probably the term that 
best describes the Computer Society’s 
standards activities. From a handful of 
volunteers working on computer termi¬ 
nology in the late 1970s, our program 
has grown to more than 5,000 people 
involved with more than 150 standards 
and projects in such diverse areas as 
software engineering, local area net¬ 
works, microprocessors, design auto¬ 
mation, vocabulary, programming 
languages, and standards definitions. 
These standards have widespread 
effects on products and practices 
throughout all sectors of the global 
economy. 

Nearly all standards projects are 
sponsored by technical committees. The 
nine committees currently sponsoring or 
cosponsoring standards work are the 
TCs on Computer Communications, 
Computer Languages, Computer Secu¬ 
rity and Privacy, Design Automation, 
Microprocessors and Microcomputers, 
Operating Systems, Simulation, Soft¬ 
ware Engineering, and Test Tech¬ 
nology. 

Other organizations often have a 
major interest in a standard, and this 
sometimes leads to joint sponsorship. 
For example, the Computer Society and 
the Standards Committee X3 on Infor¬ 
mation Processing Systems jointly 
sponsor work on the programming lan¬ 
guage Pascal. 

Standards are developed within work¬ 
ing groups named by their project num¬ 
ber and title (for example, P1003.1 
Portable Operating Systems Environ¬ 
ments). Working groups are made up of 
technical experts and representatives of 
vendors and users of computer technol¬ 
ogy who have an interest in the stan¬ 
dard being developed. When a topic 
spans the interests of a number of TCs, 
then the Standards Coordinating Com¬ 
mittee serves as the sponsor. This is the 
case for our work on terminology stan¬ 
dardization and on computer-aided 
software engineering tools. 

Often a technical committee 
organizes a standards subcommittee to 
oversee the TC’s standards program. 
Working groups and standards subcom¬ 
mittees meet anywhere from one to six 
times per year. These meetings are open 


to all interested parties, but you don’t 
have to be present to influence the 
direction of a standard. Written com¬ 
ments and contributions are welcomed. 

The Computer Society Standards 
Activities Board (SAB) is responsible 
for recommending to the Board of 
Governors all policies and practices 
with respect to standards. The SAB 
meets three times a year in conjunction 
with meetings of the Computer Society 
Board of Governors. The vice president 
for standards chairs the SAB. 

The Standards Coordinating Com¬ 
mittee (SCC), chaired by Paul Borrill, 
reports to the SAB and is responsible 
for monitoring the development and 
maintenance of standards. SCC meet¬ 
ings are held in conjunction with SAB 
meetings. 

All new standards projects must be 
formally “blessed” by the IEEE Stan¬ 
dards Board. Once development work is 
completed, the proposed standard is 
submitted to the IEEE Standards Board 
for consideration. When approved by 
the IEEE, the standard is automatically 
forwarded to the American National 
Standards Institute (ANSI) for adop¬ 
tion as an American National Standard. 

The IEEE is accredited by ANSI as a 
standards development organization. 
Other accredited organizations sponsor¬ 
ing standards activities in the computer 
field include the Computer and Busi¬ 
ness Equipment Manufacturers Associ¬ 
ation and the Electronics Industries 
Association. 

Sometimes interest in a particular 
standard is so great that it is formally 
submitted to recognized international 
standards organizations for consider¬ 
ation. A number of Computer Society- 
sponsored standards have gone on to be 
accepted by the International Standards 
Organization and the International 
Electrotechnical Commission. 

Four times a year the Computer Soci¬ 
ety issues the “Standards Status 
Report,” containing the latest informa¬ 
tion on completed standards, active 
projects, and points of contact. Often 
working groups and subcommittees 
make their documents available to the 
general public for information and 
comment. Copies of the status report, 
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draft documents, and completed stan¬ 
dards can be purchased through the 
Computer Society’s Publications Office 
in Los Alamitos, California, European 
Office in Brussels, and Asian Office in 
Tokyo. (For addresses and phone num¬ 
bers, see the Computer Society Infor¬ 
mation Page on the inside back cover.) 

Late last year the Board of Governors 
approved the hiring of a full-time stan¬ 
dards support coordinator in the Wash¬ 
ington, DC, office. Richard Cain joined 
us shortly thereafter and should be your 
first point of contact for information 
on the society’s standards activities. 

The board also approved a significant 
increase in the standards activities 
budget for 1988. Armed with increased 
staff and funding, we are making major 
improvements in support services 
offered to working groups and subcom¬ 


mittees and in increased publicity about 
standards developments. 

These are exciting times in the world 
of standards. If you are not already 
doing so, I invite you to consider 
becoming active in the Computer Soci¬ 
ety’s standards program. There is 
always room for new ideas and creative 
solutions, along with the blood, sweat, 
and tears that are ubiquitous in this 
business. 

Helen M. Wood 

First vice president, standards 


| ANSI | 


IEEE 



I 


Computer 

Society 



Organizational structure for standards 
development and approval. Among the 
standards recently approved by the 
IEEE and available from the Computer 
Society are IEEE Standard 1014-1988, 
Versatile Backplane Bus: VMEbus 
(Computer Society Order No. 981), 
IEEE Standard 1076-1988, Standard 
Description Language for Electronic 
Hardware (CS No. 983), and IEEE 
Standard 802.3 a,b,c,e-1988. Supple¬ 
ments to Carrier Sense Multiple Access 
with Collision Detection (CS No. 984). 
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Multicomputers: 
Message-Passing Concurrent 
Computers 

illiam C. Athas and Charles L. Seitz 


v> 

A 
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California Institute of Technology 


H ighly concurrent computers 
achieve remarkable perfor¬ 
mance on the broad class of 
computations that can be formulated and 
expressed as concurrent programs. This 
performance is scalable in the number of 
computing elements, open-ended with 
technology advances, and low in cost. 
Several highly concurrent or highly paral¬ 
lel systems are now commercially avail¬ 
able, and innovative programmers are 
applying them successfully to a great vari¬ 
ety of demanding computing problems. 

This article provides a status report on 
the architecture and programming of a 
family of message-passing concurrent 
computers that have evolved out of the 
research of the DARPA-sponsored Sub¬ 
micron Systems Architecture Project in 
the Caltech Computer Science Depart¬ 
ment. These systems are organized as 
ensembles of sm all programmable co m¬ 
put ers, callecf nodes, connect ed by a 
rtjessag g-p^ssir'f? (see Figure 1). 

This multiple-computer structure has fit¬ 
tingly come to be known as a mul- 
i ticomputer. 

First-generation multicomp uters 
L include the Cosmic Cu be 1 antTTne well- 
known commercial hypercube multicom- 


Attacking a large 
computing problem 
with a myriad of 
small programmable 
computers requires a 
combination of 
architecture, 
programming systems, 
and program 
formulation. 


puters; more th an one hundred q £* h«sq 
machines are curren tly in use. Second! 
ge nerati on multicomputers with"'T&ster\ 
"nocles antttnuch faster message-passing 
networks appeared during the past year. 
Configurations of these systems with as 

00 18-9162/88/0800-0009501.00 C 1988 IEEE 


few as 64 nodes exhibit performance com¬ 
parable to that of conventional supercom¬ 
puters on a wide variety of large 
computing problems. 2,3 

Multicomputer programming. The 

usual abstract unit in which a multicom¬ 
puter computation is formulated, a pro¬ 
cess, is an instance of a program. Just as 
an electrical circuit might contain many 
instances of a certain type of component, 
and many types of components, a concur¬ 
rent computation might contain many 
instances of one or more programs. The 
programs might be written in conventional 
programming notations, such as C, For¬ 
tran, Pascal, or Lisp, with a standard 
library of functions or subroutines that 
cause messages to be sent and received. 
Other functions that cause the creation 
and destruction of processes allow inter¬ 
mediate results to determine dynamically 
thg distribution of a computation. 

X 'A process contains its own code and pri¬ 
vate variables, and coordinates its activi¬ 
ties with other processes by sendi ng an^ L 
receiving messages. To^uppuu itrCprocess 
multicomputer nod e 
runs a multiprog ramming operating sys¬ 

tem that allows multiple processes to coex- 
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processor can reduce the volume of 
accesses through the switch network; how¬ 
ever, use of a cache for global variables 
requires a mechanism that allows the cache 
memories to discover when a global vari- 


. iiicni lu uiacuv 
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in mntp^g t } the messag e-passing mul- 
tjpnmpnw itj hr>|[i logically ana pny slcally 


a distrihiited-memorv system . Theproces- 


N computing nodes 


Figure 1. Programmer’s model of a multicomputer. 



Figure 2. 64-node binary n-cube network (a), and two-dimensional mesh network 
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ist within that node . Accordingly, the 
number of concurrent processes involved 
in a single computation can greatly exceed 
the number of nodes. 

Physical architecture. Multiple- 
instruction, multiple-data parallel com¬ 
puters divide into twflmajor types: shared- 
memorv mult iprocessors' and messaee- 
j^assing multicojii(^ersr-WecanTliicoV“ 
uh^xeasofiTfor many design choices used 
in multicomputers by comparing them 
with multiprocessors. 

The logical structure of a shared- 
memory multiprocessor allows multiple 


processors to access memory in a single 
global address space. The aggregate 
demand on the global memory from a 
large number of processors dictates a num¬ 
ber of memory elements comparable to the 
number of processors; hence, the shared ■ 
global memory is a nhv sicallv distribu ted \ 
merprn w. that sp ans jKej do bal a ddress | 


Space.’ Multiprocessors with large 
"of processors employ ^ swi tch network 
that allows any processorto cbwnect toany 
memory. Some switch networks support a 
technique of combining references to, and 
operations on, the same storage location. ( 


_ n each nod e computer isTigiillycou- 

pl ed to a memory that is physically 

separate and logical ly'private ironrthe 
1 memories of the other ItodecOmputers. A 
-aloha! memory address does not exist ; 

rather, each node has its own private mem- 

ory address space. The fixed numbering of 
_ the nodes, 0,1,. . . , N - 1, together with 
the unique numbering of the processes 
within each node, establishes globa lly 
unique identifiers for pro cess es; hence , a 

global name space. 

Interprocess communication in a mul¬ 
ticomputer occurs by ro u ting message s 
i through a network such asa binary n -cube 
] or mesh (see Figure 2). Regular networks 
simplify the routing. Their direct and 
bidirectional, as opposed to indirect, 4 
structure allows process placement to 
exploit the loi Lalirv-tj f co mmu nications. 
The networks are alsoexfensmleTor'scaP' 
able, to allow for systems with different 
numbers of nodes. The individual chan¬ 
nels operate at rat es comparable to~ ~rTie" 
md mSry^andwM ElQlla node; the nodes 
■cSnnot generate or absorb messages at a 
higher rate. The number of bits conveyed 
in parallel on a channel is typically less 
than the word length of the node memory, 
while messages are typically at least a few 
words long; hence, the xnessaae is-sy ial- 
i xed in to a s^trcmcr Trnw;illi--l-dato.iinii^ 
rthiit weTefer to as flow control units, or 


Latency issues. The network latency 
equals the time from when the head of a 
message enters the network at the source 
until the tail emerges at the destination. 
Since the flits move through the network 
in a pipeline fashion, the network latency 
equals the sum of two components: 

• TpD is the time associated with form¬ 
ing the path through the network, 
where T p is the delay of the individ¬ 
ual routing nodes encountered on the 
path, and D is the number of nodes 
traversed, or the distance. 

• L/B is the time required for a message 
of length L to pass through the chan¬ 
nels of bandwidth B. 

Multicomputer message-passing net- 


Using a local or cache memory with each I works and multiprocessor switch networks 
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have a^si xpilar function . The multicom¬ 
puter network provides a complete N x N 
connection between N nodes. The multi¬ 
processor network provides an N x M con¬ 
nection between N processors and M 
memories, where N and M have compara¬ 
ble magnitudes. Although multicomputer 
and multiprocessor networks are 
optimized somewhat differently for their 
different operating environments, the 
latest designs of both run up against the 
same physical electronic and packaging 
limitations. As we describe later, it is prac¬ 
tical to build networks of tens of nodes in 
which the path formation component of 
the network latency equals one or two 
instruction times for a processor fabri¬ 
cated using comparable technology. How- 
evet*networks with thousands of nodes 
are much more difficult to build and can 
exhibit latencies of tens of instruction 
times. 

The performance of conventional 
instruction processors is quite sensitive to 
memory-access latency, the delay from 
when the processor emits an address to 
when the data is returned from memory. 
Interprocess communication in a multi¬ 
processor occurs through the shared global 
memory. If the memory-access latency 
exceeds about one instruction time, the 
processor must idle until the storage cycle 
completes. Unless multiprocessor 
designers can discover methods to imple¬ 
ment switch networks with lower latency 
or develop processors that are less sensitive 
to the memory-access latency, scaling mul¬ 
tiprocessors into the range of thousands of 
nodes will be impractical. 

Separate mechanisms that distinguish 
the different requirements for processor- 
to-memory communication and inter¬ 
process communication save the mul¬ 
ticom puter from this scaling dilem ma. 
Because the processor and memory are 
physically localized in a node, the 
processor-to-memory communication is 
not a problem . Interprocess message com ¬ 
munication takes P lg e f jn -nH 

less frequen tly than memory accesses, and 
accordingl'y'Can exhibit a larger latency. 
Thus, no serious physical obstacles pre¬ 
vent scaling message-passing networks to 
support communicat ion- b e t -wegnthou- 
/sands of nodes: 

Multicomputers and multiprocessors 
are so logically similar that each can run 
wri tten for the other. PrQ gwnTts 
written in aprocess model with message- 
passing are routinely run on multiproces¬ 
sors simply by implementing the message¬ 
passing operations in the global shared 


Multicomputers and 
multiprocessors are so 
logically similar that 
each can run 
programs written for 
the other. 


memory. Programs written in a process 
model with shared variables can be com¬ 
piled to run on multicomputers bv replac¬ 
i ng assignments to shared variables with 
message-passing o perating The effi¬ 
ciency of this approach depends on how 
successfully the compiler can trace the data 
dependencies and manage the communi¬ 
cations. Both multicomputers and mul¬ 
tiprocessors can execute programs 
formulated for single-instruction, 
multiple-data message-passing parallel 
computers, such as the Connection 
Machine, 5 but such machines cannot effi¬ 
ciently execute programs that exploit the 
ability of multiple-instruction, multiple- 
data machines to run different programs 
on different processors. 

Grain size. Although no single or per¬ 
fect definition of grain size exists for mul¬ 
ticomputers, the term loosely describes 
node siz e o r com plexity. 4 We refer to 
^^ ^ BmmB fita rrwTnTse no des rentnin 
megabytes of memory as medium-yr ain 

machines, and to those whose node£.con- 
*~^fc t i n te ns o f ltiloby Lis Ul mu nory as fine- 
‘ r grain machin e^ — * 

Suppose we were to design a large-scale 
multicomputer with one gigabyte of pri¬ 
mary storage. We might partition this stor¬ 
age into four-megabyte units for each of 
256 nodes. We could package the inte¬ 
grated circuits for one node on a single cir¬ 
cuit board or multichip carrier. Suitable 
programming environments for this 
medium-grain machine are directly com¬ 
patible with programming environments 
hosted on workstations. 

However, because multicomputers have 
few advantages over multiprocessors for 
small N, and because multiprocessors can 
simulate multicomputers more effectively 
than vice versa, consider the alternative of 
shifting Ninto a “niche’ ’ where multicom¬ 


puters are still feasible but multiprocessors 
are not. For example, the same one giga¬ 
byte of storage might also be used for a 
fine-grain multicomputer with 32,768 
nodes, each with 32 kilobytes of primary 
storage. This system could exhibit peak 
concurrency more than two orders of mag¬ 
nitude higher. A node would fit on a sin¬ 
gle very-large-scale-integration chip and 
would be extremely fast, given the advan¬ 
tage of processor-to-memory communica¬ 
tion being localized to the chip. 

Programming environments. A mul¬ 
ticomputer includes one or more nodes 
with interfaces to a local area network, 
and/or one or more computers with inter¬ 
faces to both the multicomputer’s 
message-passing network and a local area 
network. Either of these configurations 
allows messages to be passed between pro¬ 
cesses in the multicomputer nodes and 
processes in network hosts, such as the 
user’s workstation. Thus, multicomputers 
fit naturally into network computing envi¬ 
ronments and depend on the network 
hosts not only for preparing and compil¬ 
ing programs, but also for initiating and 
interacting with computations running on 
multicomputers. 

The programming systems for medium- 
grain multicomputers have evolved 
through use for several years. Process code 
for an explicit concurrent formulation of 
a computing problem is written in famil¬ 
iar programming languages extended with 
a library of process-spawning and 
message-passing functions. 

Our research group developed the Cos¬ 
mic Environment and Reactive Kernel sys¬ 
tems to support this multiple-process 
message-passing programming environ¬ 
ment 6 on network hosts and medium- 
grain multicomputer nodes, respectively. 
The CE host runtime system consists of a 
set of daemon processes, utility programs, 
and libraries. It can serve as a stand-alone 
system for running message-passing pro¬ 
grams on collections of.network- 
connected Unix hosts. It can also handle 
the allocation of, and interfaces to, one or 
more multicomputers. When interfaced to 
a multicomputer, it supports uniform 
communication between host and node 
processes. The RK node operating system 
supports multiprogramming, message- 
driven process scheduling, storage 
management, and system calls for 
message-passing and other functions on 
each node. 

CE and RK together provide uniform 
communication between processes 
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Figure 3. Intel iPSC/2 node (top) and vector accelerator (bottom). 


independent of the multicomputer node or 
network host on which they happen to be 
located. These systems allow message¬ 
passing programs to be run not only on 
multicomputers, but also on shared- 
memory multiprocessors, across networks 
of workstations, and on sequential com¬ 
puters. A principle and a formal property 
of the entire CE/RK system—within the 
limits of the computation being deter¬ 
ministic and not exceeding available stor¬ 
age sizes—is that the results of a 
computation do not depend on the distri¬ 
bution of the processes. 

Programming systems that support 
fine-grain concurrency are in their early 
stages of development. These systems are 
based on new programming languages that 
provide constructs for expressing fine- 
grain concurrency. Although many pro¬ 
gramming languages and language con¬ 
structs have been proposed, two general 
approaches for expressing fine-grain con¬ 
currency have emerged. 

One approach is based upon a static 
process structure in which the number of 
processes and their connectivity is known 
before the program executes. In Occam, 7 
for example, all processes and channels for 
a computation are denoted in the source 
program. Each channel connects exactly 


two processes, and communication 
through the channel is synchronous; that 
is, the completion of the send action at one 
end of the channel is synchronized with the 
completion of the receive action at the 
other end. The Occam compiler performs 
an operation analogous to macro expan¬ 
sion on processes and channels, resulting 
in the static process structure. 

The other general approach is based 
upon dynamic process structures in which 
processes are created and destroyed on 
demand. Message passing is accomplished 
by reference to the destination process 
rather than to a channel, and is asyn¬ 
chronous and buffered. Because refer¬ 
ences to processes can be communicated in 
messages, the connectivity of the process 
structure can vary as the computation pro¬ 
ceeds. The Actor model 8 and program¬ 
ming notations, and the Cantor 
programming system, 9 which we describe 
later, exemplify this approach. 


Medium-grain 

multicomputers 

Between 1981 and 1985, members of our 
research group designed, built several 


copies of, and developed the system soft¬ 
ware for the Cosmic Cube, 1 an experi¬ 
mental message-passing concurrent 
computer that became the archetype of the 
first-generation multicomputers. Com¬ 
mercial multicomputers that use the same 
organization and programming 
methods—the Intel iPSC/1, Ametek 
S/14, and N-Cube/10—were introduced 
in 1985. The size of a single node in these 
systems ranges from seven chips (one cus¬ 
tom VLSI chip with processor and com¬ 
munications, plus six RAM chips) in the 
N-Cube to two circuit boards (a regular 
node board plus a vector accelerator 
board) in the Intel iPSC/1 VX. 

All of these systems use software- 
controlled routing on a binary n -cube net¬ 
work to connect N = 2" nodes; hence, 
they are sometimes called cubes or hyper¬ 
cubes. The number of nodes in a single sys¬ 
tem ranges from four (two-dimensional 
cube) t o 1.024 (10-dimensional cube) . The 
Floating Point Systems T-Series and other 
machines based on the Inmos transputer 7 
are also multicomputers, but they employ 
a computational model based on the 
Occam programming language. 

These first-generation multicomputers 
have proven to be reasonably “general- 
purpose” concurrent computers. They 
have been applied to a wide range of eas¬ 
ily partitioned and distributed computing 
problems, such as matrix operations, 
differential equation solvers, finite ele¬ 
ment analysis, finite difference methods, 
distant- or local-field many-bdcfy prob¬ 
lems, fast Fourier transforms, ray tracing, 
heuristic searches, circuit simulation, and 
distributed simulation of systems com¬ 
posed of loosely coupled physical pro¬ 
cesses. Hundreds of research papers and 
reports have been published on the concur¬ 
rent formulations and results of these com¬ 
putations. 

Current status. Multicomputers cur¬ 
rently stand at the threshold of a second 
generation of medium-grain machines. 
The nodes of these systems employ the 
same 32-bit processor and megabit RAM 
technology used in personal computers 
and workstations. In comparison with 
first-generation machines, node perfor¬ 
mance and memory capacity have 
improved by nearly an order of magnitude 
within the same physical size simply by 
tracking the advances in single-chip 
processor and RAM technology. How¬ 
ever, second-generation multicomputers 
are most distinguished by message-routing 
hardware that makes the topology of the 
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message-passing network practically 
invisible to the programmer. 

The message-routing hardware employs 
a blocking variant of cut-through routing 
that we call wormhole routing. 1012 A mes¬ 
sage consists of a sequence of flits, in 
which the flit at the head of the message 
governs the route. As the head flit 
advances along the specified route, the 
remaining flits follow in a pipeline fashion. 
If the head encounters a channel already 
in use, it is blocked until the channel is 
freed; the flow control within the network 
blocks the trailing flits. 

This form of routing and flow control 
has two important advantages over the 
store-and-forward packet cut-through 
routing used in first-generation machines. 
First, it avoids using storage bandwidth in 
the nodes through which messages are 
routed. To the designer of a multicom¬ 
puter, the storage bandwidth of a node is 
a precieusjesource that should be spent on 
computing -cycles rather than message 
routing. Second, this routing technique 
makes the message latency largely insen¬ 
sitive to the distance in the message¬ 
passing network. The network latency, 
T P D + L/B, is dominated by the second 
term in the sum for all but very short mes¬ 
sages. For example, in one implementation 
in which T p ~ 80 nanoseconds and B~ 25 
megabytes per second, a 40-byte messa ge 
that traverses five nodes would require 3.4 
microsecond for path formation, but 1.6 
microseconds to convey the message. 
Also, the fixed software overhead of sys¬ 
tem calls and context switching is much 
larger than the network latency. 

Another improvement in message per¬ 
formance results from using lower- 
dimension and higher-radix versions of the 
k -ary n-cube network. 4 We can think of 
a k -ary n-cube—a family of torus net¬ 
works with k" nodes—as constructed in n 
dimensions with k periodic coordinates in 
each dimension. This family includes the 
binary (2-ary) a- cube (see Figure 2) net¬ 
work on one extreme and the k -element 
ring network (A:-ary 1-cube) at the oppo¬ 
site extreme, and spans a range of wirabil- 
ity and average distance between pairs of 
nodes. 

An analysis of the cost and performance 
of these networks must take into account 
that the more wirable networks can afford 
to assign more parallel wires, hence a 
higher bandwidth, to each channel. The 
optimization to minimize latency simply 
minimizes T P D + L/B. High-dimension 
networks reduce the first term at the 
expense of the second, while low- 


dimension networks reduce the second 
term at the expense of the first. An 
analysis" shows that a two-dimensional 
network minimizes latency for typical mes¬ 
sage lengths for N~ 256. 

The two-dimensional mesh (see Figure 
2) is a variation on a A:-ary 2-cube with the 
“end-around” cyclic connection elimi¬ 
nated. We prefer the mesh rather than the 
torus form of the cube because the mesh 
offers useful edge connectivity. Also, the 
mesh partitions into units that are still 
meshes, and the particular deadlock-free 
routing scheme used is simpler when the 
cyclic connection is eliminated. 10 Based 
on this reasoning, we expect that two- 
dimensional mesh networks will become 
the standard for second-generation 
machines. 

Intel and Ametek recently introduced 
two early second-generation multicom¬ 
puters. The Intel iPSC/2 2 is an upgraded 
Intel iPSC/1, with nodes based on the Intel 
80386 processor and hardware wormhole 
message routing in the binary n -cube. Fig¬ 
ure 3 shows an iPSC/2 node. The Ametek 
Series 2010 3 uses the Motorola 68020 as 
the node instruction processor, a 
microprogrammed second processor to 
manage the send and receive queues, and 
a two-dimensional wormhole routing 
mesh network. Figure 4 shows parts of two 
4x4 submesh units of the Ametek Series 
2010 and the way they are attached. Our 
research group developed the mesh rout¬ 
ing chips 12 ; MOSIS (Metal-Oxide Semi¬ 
conductor Implementation Service) 
provided the fabrication. Both the iPSC/2 
and the Series 2010 run the CE/RK pro¬ 
gramming environment. 

In comparison with first-generation 
multicomputers, node performance has 
improved by nearly an order of magni¬ 
tude, while the reduction in message 
latency for nonlocalized messages in the 
Series 2010 approaches three orders of 
magnitude. The relationship between 
communication and computing perfor¬ 
mance improved by two orders of magni¬ 
tude. Faster communications extend the 
application span of multicomputers from 
easily partitioned and distributed prob¬ 
lems to high-flux problems, such as search¬ 
ing, sorting, concurrent data structures, 11 
graph problems, signal processing, image 
processing, and distributed simulation of 
systems composed of many tightly coupled 
physical processes. Making the message 
latency insensitive to message distance 
simplifies programming and allows more 
effective and less constrained dispersal of 
processes to achieve'load balance. 



Figure 4. Close-up of a region of the 
Ametek Series 2010 backplane. 


Configurations. We can scale and con¬ 
figure medium-grain multicomputers in 
several ways. The number of nodes, N, is 
the most important scaling. Node memory 
size is another configuration choice. The 
preferred node memory size will likely 
approximate that in workstation com¬ 
puters, with nodes operating as virtual 
memory computers. 

Although the first-generation systems 
are homogeneous—that is, the nodes are 
nominally identical—we can construct 
multicomputers equally well as heter¬ 
ogeneous systems with a variety of special¬ 
ized nodes for different computations, so 
long as all the nodes employ the same com¬ 
munication protocols. One form of heter¬ 
ogeneous multicomputer system already 
exists in the installation of different 
accelerators on different nodes, such as an 
Intel iPSC/1 configured with floating¬ 
point vector accelerators on half of the 
machine and memory expansion on the 
other half. We can also install I/O device 
controllers—such as those for disks, dis¬ 
plays, and communications—on individ¬ 
ual nodes or around the edges of the mesh. 
With disk interfaces, second-generation 
multicomputers support their own file sys¬ 
tems and can even act as high-performance 
file servers for a network. 

Third-generation systems. To place 
these developments into a long-term per- 
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Table 1. Medium-grain multicomputer history and projections. 


Generation 

Years 

First 

1983-87 

Second 

1988-92 

Third 

1993-97 

Typical node 

MIPS 

1 

10 

100 

Mflops scalar 

0.1 

2 

40 

M flops vector 

10 

40 

200 

memory (Mbytes) 

0.5 

4 

32 

Typical system 

N (nodes) 

64 

256 

1,024 

MIPS 

64 

2,560 

100K 

Mflops scalar 

6.4 

512 

40K 

Mflops vector 

640 

10K 

200K 

memory (Mbytes) 

32 

IK 

32K 

Communication latency (100-byte msg) 

neighbor (microseconds) 

2,000 

5 

0.5 

nonlocal (microseconds) 

6,000 

5 

0.5 
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Figure 5. Cosmic Environment display showing how multicomputers on a network 
are allocated in “space-sharing.” 


spective, we observe that in accordance 
with the technology development model in 
the DARPA Strategic Computing pro¬ 
gram, the first-generation machines used 
relatively unaggressive technology to 
establish the computational model, pro¬ 
gramming methods, and applications. The 
second-generation systems achieve much 
higher performance by a combination of 


organizational refinement and VLSI tech¬ 
nology. 

Since multicomputers are scalable in size 
and technology, we expect that a third 
generation can develop with little 
organizational change from the second 
generation, requiring only the application 
of VLSI technology advances. The use of 
VLSI with smaller-sized features will scale 


processor and communication perfor¬ 
mance together. Thus, we do not expect 
the relationship between communication 
and computing performance to change sig¬ 
nificantly in the further evolution of these 
architectures. The most important 
organizational improvements in the third 
generation will be in the instruction 
processors, both in their performance and 
in their ability to switch context more effi¬ 
ciently than processors designed for use in 
personal computers and workstations. 

Table 1 summarizes our projections of 
the evolution of medium-grain multicom¬ 
puters. 

Medium-grain 
concurrent programming 

In preparation for an example of pro¬ 
gramming medium-grain multicomputers 
using a process model, we will describe 
several of the essential features of the Cos¬ 
mic Environment and Reactive Kernel sys¬ 
tems. 6 We will illustrate the user-interface 
functions and example using the C pro¬ 
gramming language. 

Process groups. The entire set of pro¬ 
cesses involved in a single computation is 
called a process group. A CE utility pro¬ 
gram establishes the process group and 
allocates the multicomputer nodes, and 
thereafter manages the entry of the host 
process into the process group, the mes¬ 
sages between them, and the messages to 
and from any node processes. 

Multicomputers are normally not time- 
shared, but space-shared. A CE utility dis¬ 
plays how all the multicomputers on a net¬ 
work are allocated, as well as the user’s 
own host processes (see Figure 5). In this 
example, the 128-node iPSC d7 is allocated 
with one user (wen-king) running a com¬ 
putation on a 6d ipse cube (64 nodes), 
another user (lena) on a 5d ipse cube (32 
nodes), and the remaining 5-cube free. Of 
course, the user with 64 nodes cannot dis¬ 
tinguish these 64 nodes from a separate 
64-node multicomputer. The logical node 
numbers will be 0,1, • • ■ , 63, regardless 
of their physical location in the mul¬ 
ticomputer. 

Space-sharing has proven most appro¬ 
priate for multicomputers because it 
allows a user to select a number of nodes 
appropriate to the number of processes 
and the load-balancing characteristics of 
a particular computation. It also produces 
predictable runtimes and does not allow 
one user’s processes to upset the load bal- 
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ance of another process group. 

The ghost cube in the display of Figure 
5 is not a real multicomputer, but mimics 
one with a collection of 16 CE daemon 
processes distributed across a set of work¬ 
stations on the local network. Using ghost 
cubes, sites that do not have regular access 
to a multicomputer have developed many 
multicomputer programs. 

Process IDs, placement, and spawning. 

Every process within a process group has 
a unique identifier (ID), represented as an 
ordered pair: (node, pid). A value of the 
node parameter in the range 0 . . . N - 1 
designates a node process; otherwise, a 
host process. The pid part of the ID speci¬ 
fies a particular process within a node or 
within the host environment. The mynode, 
mypid, and nnode functions permit a pro¬ 
cess to determine its own ID and the num¬ 
ber of nodes. 

Processes in execution can freely spawn 
and kill other processes. The system’s 
lowest-level process-spawning mechan¬ 
isms give the programmer explicit control 
of process placement through the argu¬ 
ments of a dynamic process-creation func¬ 
tion, spawn(“filename”, node, pid, 
“mode”). The node parameter determines 
process placement, and contrary to the 
usual practice in which the operating sys¬ 
tem assigns a pid, the pid is specified in the 
function. This scheme allows processes to 
build structures in which references to 
other processes are predetermined, rather 
than established by passing references in 
messages. 

Process placement and IDs can also be 
decided dynamically during execution; 
other process-creation functions support 
this option. Functions also exist for creat¬ 
ing a process in every node from the same 
“filename” specification. Fast process 
creation is crucial to the performance of 
many multicomputer computations. 
Accordingly, RK not only shares code seg¬ 
ments for processes created from the same 
compiled program (“filename”), but also 
caches a copy of the initial data segment so 
that subsequent processes with the same 
“filename” specification can be created 
without accessing the file system. 

Execution of spawn functions in host 
processes is how a computation that starts 
out as a process running on a host com¬ 
puter builds the process structure for a 
computation that runs on a mul¬ 
ticomputer. 

Once spawned, a process will not spon¬ 
taneously migrate to another node; thus, 
it is most efficient to retain the physical 


location of a process as a part of its unique 
ID. One of the implicit premises of mul¬ 
ticomputer architectures is that costly 
communication mechanisms for dynami¬ 
cally binding computing resources to runa- 
ble objects, as used in multiprocessors or 
in the dataflow model, are rarely neces¬ 
sary. It is instead sufficient for most prob¬ 
lems to establish a binding of a process to 
a node that will persist for the life of the 
process. Although the CE/RK environ¬ 
ment does not relocate processes, high- 
level programming systems that support 
dynamic relocation of processes are easily 
layered on top of the CE/RK environment. 

Messages. A message is the logical unit 
of information exchange between pro¬ 
cesses. A message can be any number of 
bytes in length, from zero to any size that 
will fit in the memory of the nodes of the 
sending and receiving processes. Although 
message length or destination select differ¬ 
ent protocols for packetizing and routing 
messages, these differences are invisible to 
the application programmer. 

Sending a message between processes 
requires that the sending process have 
reference to the receiving process. Refer¬ 
ences are represented in message functions 
as IDs. The process structure —which we 
define as the set of processes within the 
process group, together with each 


process’s references to other processes— 
can be depicted as a directed graph with 
vertices representing processes and arcs 
representing references. We can also 
visualize the arcs as virtual communication 
channels, with messages traveling along 
the arcs (see Figure 6). 

Messages are queued as necessary in the 
sending node, in transit, and in the receiv¬ 
ing node. Accordingly, they have arbitrary 
delay from sender to receiver. However, 
message order is preserved between pairs 
of communicating processes; for example, 
if process A sends two messages in 
sequence to process B, they will arrive an 
arbitrary time later and in the same order 
as they were sent. Thus, we can think of 
the messages in Figure 6 as ‘ ‘traveling” at 
some arbitrary speed, but one message 
cannot pass another on a reference arc. 

For the C-language user-interface rou¬ 
tines to the CE/RK system, messages are 
sent and received from dynamically allo¬ 
cated storage accessed both by user pro¬ 
cesses and by the message system. Message 
buffers are blocks of memory with no pre¬ 
sumed structure; thus, messages can con¬ 
vey arbitrary structures, such as simple 
variables, arrays, or user-defined types. 

The xmalloc and xfree functions can 
allocate and free message space. These 
functions are semantically identical to the 
Unix malloc and free functions. When a 
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^include <cube/cubedef.h> 


typedef struct MESG MESG; /* Message header structure. */ 

struct MESG {int pnode, ppid; /* ID of the parent process. */ 

int tbase ; /* Base for time-on-target tree. «/ 

int len ; /* Number of elements in the vector. */ 

MESG **type ;} ; /* Type field for filtering message. */ 

^define BUF(v) ((double *)(v+ 1)) /* Data follows MESG immediately. */ 


unsigned int this_node, this_pid, node_cnt; 
main() 

{ MESG *v; 

this_node = mynode(); 
this_pid = mypid(); 
node_cnt = nnodes(); 
v = (MESG *) xrecvb(); 
mergesort(v); 

xsend(v, v- > pnode, v- >ppid); 

} 

mergesort(v) 

MESG *v ; 

{ unsigned kl, k2, i, new_node; 

MESG *vl, *v2, *vtemp; 
double *d, *s, *bl, *b2; 

if(v— >len <= 1) return; 
kl = (v- >len + 1 ) / 2; 
k2 = (v - > len ) / 2; 
vl = (MESG *) xmalIoc(sizeof(MESG) + sizeof(double)*k 1); 
v2 = (MESG *) xmalloc(sizeof(MESG) + sizeof(double)*k2); 
for(i = vl - >len = kl, d = BUF(vl), s = BUF(v); i~;) *d++ = *s+ +; 
for(i = v2- >len = k2, d = BUF(v2) ; i~;) *d++ = *s++; 


/* node number of this process. */ 
/ * pid number of this process. */ 

/* number of nodes in this machine. */ 
/* Receive list from parent process. */ 
/* Sort the list. */ 

/* Send list back to parent. */ 


/* len = 1 lists are already sorted. */ 
/* Break the list into two lists. */ 


new_node = this_node ~ v - > tbase; 

vl - >tbase = v2- >tbase = v- >tbase < < 

if (vl - >len > 20 && new_node < node_cnt) 
{ 

spawn(“msort”,new_node,this_pid,“ ”); 
vl - >pnode = this_node ; 

vl->ppid = this_pid ; 

vl->type = &vl ; 

xsend(vl,new_node,this_pid); 
vl = 0; 

} 

else mergesort(vl); 


/* Next node in the tree. */ 
/ * New base for building */ 
/* the time-on-target tree. */ 

/* If list is long enough */ 
/* and next node exists, */ 
/ « spawn a child process */ 
/* and send it a list. */ 

/* The type field holds the */ 
/* address of the msg ptr. */ 
/* Msg ptr is set to nil. */ 

/* Sort vl if can’t split. */ 


mergesort(v2); 


/* Sort the second list. */ 


while(lvl) { vtemp = (MESG *) xrecvb(); *vtemp- >type = vtemp; } 

for(bl = BUF(vl), b2 = BUF(v2), d = BUF(v); kl || k2;) /* Merge. */ 
{ while(kl &&(!k2 || (k2&&bl <= *b2))) { kl~; *d+ + = *bl++;} 
while(k2&&(!kl || (kl &&b2 <= *bl))) { k2-; *d++ = *b2++;} 

} 

xfree(vl); xfree(v2); 


Figure 7. Program text for a mergesort process. 


message has been built in a message block 
pointed to by p, its contents can be sent as 
a message by the function xsend(p, node, 
pid). The xsend function also deallocates 
the message space; that is, xsend(p, ...) 
resembles xfree(p), except that it also sends 
a message. Thus, there is no need for 
blocking or for feedback that the message 
has been sent; when the function returns, 
the message block is gone. 

The function xrecvb can receive mes¬ 
sages and return a pointer to a new mes¬ 
sage. This blocking function does not 
return until a message has arrived for the 
process. The execution of the xrecvb func¬ 
tion is just like allocating a message buffer 
with xmalloc, except that the message 
received determines the contents and 
length of the block allocated. Once the 
message contents are no longer needed, the 
allocated space should be freed. Of course, 
xfree(p) can free the message space, but so 
can xsend(p,...) if there is a message of the 
same length to send. Frequently in 
message-passing programs, as in a later 
example, a message is received, modified 
by a computation, and then sent on to 
another process. 

If process A calls xrecvb when the next 
message in the node’s receive queue is for 
process B, RK might save the state of pro¬ 
cess A and start running process B. The 
appearance of xrecvb in the code marks 
choice points for switching the execution 
to another process; in this sense the 
scheduling is reactive or message driven. 
So long as a process makes progress, RK 
does not necessarily force a context switch 
unless some exceptional system event 
occurs. 

Portability. The C-language primitives 
described here are system primitives, and 
not necessarily those the user would find 
most convenient. We selected these func¬ 
tions for reasons of portability, and 
because we can easily and efficiently layer 
other message primitives on top of them. 
For example, the usual interface routines 
for Fortran are expressed in terms of the 
x primitives (such as xsend and xrecvb), 
but include message types and can exercise 
discretion in receiving messages by type 
and sender ID. The CE/RK environment 
also includes a sizable library of other 
functions, including many compatible 
with Unix functions of the same name, 
such as the C-language standard I/O 
package. 

A multicomputer interprets the x func¬ 
tions by allocating storage and by sending 
and receiving messages. A multiprocessor 
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Figure 8. Sequence of building a time-on-larget tree. 


can interpret the same functions differ¬ 
ently. The xmalloc and xfree functions 
allocate or free blocks in global shared 
memory. The xsend(p, node, pid) function 
passes ownership of the block pointed to 
by p to process (node, pid), and appends 
the pointer to the task queue of this pro¬ 
cess. The xrecvb function is the means by 
which a process can obtain a new task. 
This alternative operational interpretation 
allows CE/RK programs to run under 
native task systems on multiprocessors, 
and will also be a means of running the 
programs on future multicomputers that 
use multiprocessor nodes. 

Programming example. Although we 
can use the functions in the low-level port¬ 
able CE/RK environment as a compilation 
target for higher-level concurrent pro¬ 
gramming notations, the low-level envi¬ 
ronment is adequate for many purposes. 
This programming system has been used 
extensively in experiments with concurrent 
algorithms and in writing useful programs 
based on explicit concurrent formulations 
of computing problems typical of those in 
science and engineering. These application 
programs are based, for example, on con¬ 
current adaptations of well-known 
sequential algorithms, on regular data- 
partitioning strategies, on the systolic 
algorithms developed for regular VLSI 
computational arrays, and on a wide vari¬ 
ety of fundamental concurrent algorithms. 

Our example uses the mergesort algo¬ 
rithm to sort a list of elements into ascend¬ 
ing order. Briefly, we can describe 
mergesort as follows: A list of length 1 is 
already sorted and is returned. A list of 
length 2 or greater is split into two lists 
whose lengths differ at most by one. 
Mergesort is applied recursively to each of 


these lists. The resulting two sorted lists are 
then merged into a sorted list that is 
returned. List elements are compared only 
in the merge operation. Mergesort requires 
0(n log n) comparisons for a list of length 
n, a minimum for sorting algorithms based 
on performing comparisons. 

Figure 7 illustrates the complete C pro¬ 
gram for our example. With the omission 
of the code in the shaded areas, the 
mergesort function within this program 
implements the sequential form of this 
algorithm. Lists are represented with a 
defined type MESG followed by a list of 
double-precision floating-point elements; 
the program could easily be modified for 
any other built-in C type. The MESG 
structure contains a member for the length 
of the list (len), and several members for 
control of data distribution in the concur¬ 
rent program. Input to the mergesort func¬ 
tion points to a MESG, and the function 
returns.when the list is sorted. 

The adaptation of this program to a 
multicomputer exploits the recursive 
divide-and-conquer strategy of the 
mergesort algorithm for distributing the 
computation across the nodes of the mul¬ 
ticomputer. Because the algorithm’s recur¬ 
sion is twofold, a straightforward 
mapping of mergesort recursive calls to 
processes would build a binary-tree pro¬ 
cess structure dynamically. However, it is 
somewhat more elegant and efficient to 
distribute the effort in a scheme in which 
a mergesort process recursively keeps half 
of the work and gives away the other half. 
As illustrated in Figure 8 by a sequence of 
snapshots of the process structure, this 
scheme also builds a tree of processes, but 
of a form that we refer to as a time-on- 
target tree. The area of the circle for each 
process is proportional to the length of the 


list it has to sort. We can systematically 
map this process structure onto N = 2" 
multicomputer nodes, as shown in the pro¬ 
cess labels. 

The calling process, labeled C in Figure 
8, invokes a sort by spawning the root 
mergesort process, labeled 0. The root 
mergesort process is nominally spawned in 
the same node as C (but potentially in any 
node). Process C then sends to process 0 
a message in the format of the MESG 
structure followed by the list to be sorted. 
It includes in the members of the MESG 
structure its own ID (or some other ID to 
which the sorted list is to be returned), 
tbase equal to one, and the length of the 
message. Having handed off the sorting 
operation, process C can proceed concur¬ 
rently with other computations until the 
sorted list is required, at which point it exe¬ 
cutes an xrecvb function. 

The main function is an outer shell that 
allows the mergesort function to be used 
as a remote procedure. In the same fash¬ 
ion that C hands off the sort operation to 
the root mergesort process, the first 
shaded portion of the mergesort function 
hands off one of the two lists resulting 
from splitting the input list, but only if the 
list is long enough to justify it (vl - > len 
> 20) and the multicomputer includes the 
target node (new_node < node_cnt). The 
distribution of the computation is 
inhibited when the individual sort opera¬ 
tions are small or when all of the nodes are 
used. The new processes spawned are each 
identified in the MESG structure with a 
type in the form of a pointer to a vl 
pointer. Returns from the recursive 
mergesort calls occur only after the com¬ 
putation has been completely distributed. 
The sorted lists from descendant processes 
can arrive in any order; thus, messages are 
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Figure 9. Photomicrograph of the Mosaic A single-chip node. 


received and the pointers to them are 
stored into vl pointers until the vl pointer 
specific to this recursive call becomes 
non-0. Then the sorted vl and v2 lists are 
merged and freed, and the mergesort func¬ 
tion returns. 

This programming paradigm of divide- 
and-conquer problems illustrates how a 
programmer can redesign a program or 
algorithm devised to run on a sequential 
computer so that, instead, it will distrib¬ 
ute the computing to a collection of iden¬ 


tical node processes. The mergesort 
algorithm performs a balanced splitting of 
a computing task, so that the computing 
load balances across the nodes of the mul¬ 
ticomputer. 

Fine-grain 

multicomputers 

Fine-grain machines are the research 
frontier of multicomputer architectures 


and programming. If a number of chal¬ 
lenging problems can be solved, these 
machines might become the prevalent 
form of this architecture. 

To understand some of the problems in 
the physical design and programming of 
such machines, members of our research 
group are developing a design and a pro¬ 
gramming system for a fine-grain mul¬ 
ticomputer called Mosaic. Because 
medium-grain multicomputers can also 
host fine-grain computations, we have 
used medium-grain machines to develop 
fine-grain concurrent programs written in 
Cantor. We thus have a substantial collec¬ 
tion of programs ready to run on Mosaic. 
Writing and instrumenting the execution 
of many diverse fine-grain Cantor pro¬ 
grams was essential for establishing the 
requirements for the Mosaic design. 

A stipulation of the Mosaic project has 
been that a node fit on a single chip. Our 
first attempt to design such a single-chip 
node resulted in the Mosaic A chip pic¬ 
tured in Figure 9. The bottom two-thirds 
of this chip is RAM—about the same frac¬ 
tion of the silicon complexity devoted to 
RAM in medium-grain nodes. The upper- 
left part of the chip includes a 16-bit 
instruction processor and program- 
controlled communication channels, and 
the upper right is ROM containing boot¬ 
strap and self-test programs. This proces¬ 
sor ran at about six million instructions per 
second, and its four communication chan¬ 
nels operated bit-serial at 2.5 megabytes 
per second. 

The software-controlled routing is the 
most serious shortcoming in this design. It 
limits the effective channel bandwidth 
near the network bisection to about 0.25 
megabyte per second, even if the nodes 
near the bisection spend all of their time 
routing messages. A machine with 1,024 
nodes in a two-dimensional 32 x 32 mesh 
would have only 16 megabytes per second 
of bilateral message bandwidth across its 
network bisection to support 5,120 MIPS 
peak. 

Our current node design, the Mosaic C, 
consists of a 14-MIPS 16-bit processor, 
20-megabytes-per-second routing commu¬ 
nication channels with T p = 50 nanosec¬ 
onds, and up to 16 kilobytes of RAM inte¬ 
grated onto a single VLSI chip using 
1.2-micrometer complementary metal- 
oxide semiconductor technology. The 
major sections of this chip have been 
designed, fabricated separately through 
MOSIS, and shown to work correctly. We 
expect to build a full-size machine of 
16,384 nodes in 1989, after assembling the 
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sections into a single chip and building 
some smaller prototypes. The peak perfor¬ 
mance of this experimental fine-grain sys¬ 
tem should be quite phenomenal—200,000 
MIPS for the 16,384-node machine—and 
the system will serve as a testbed for the 
development of programming systems and 
applications. 

A two-dimensional 128 x 128 network 
would be inadequate for this machine, so 
we will organize it as a three-dimensional 
32 x 32 x 16 mesh .The network bisection 
for the two-dimensional network would 
include 128 channels, in contrast with 512 
channels for the three-dimensional net¬ 
work, and the longest path would be 255 
nodes instead of 78. The execution band¬ 
width of the Mosaic will be reasonably well 
balanced with its 20,480-megabytes-per- 
second bilateral message bandwidth across 
the network bisection. The average latency 
for a 20-byte message to a randomly 
selected destination node will be about 35 
instruction cycles. 

Since the implementation of low-latency 
networks becomes increasingly difficult 
for large N, how small must the message 
latency be for the message networks in 
fine-grain multicomputers? If the program 
sequences that execute between message 
operations in the formulation of a concur¬ 
rent computation are reduced to only tens 
of instructions (or even less, as they often 
are for fine-grain program objects), is it 
not necessary to reduce the message laten¬ 
cies in proportion? Since this scaling in 
latency would be motivated by the same 
factors that cause N to be scaled up, the 
construction of fine-grain systems would 
be physically very difficult, indeed. How¬ 
ever, one of the ways multicomputers 
accommodate message latency is by main¬ 
taining multiple processes or program 
objects in each node. When a process 
attempts to receive a message not yet in the 
node’s pool of received messages, it 
switches context to another process that 
does have a message available. Maintain¬ 
ing many processes per node is also impor¬ 
tant to achieving load balance statistically. 

As we observed in connection with 
future medium-grain multicomputers, a 
reduction in context-switching time is 
increasingly important. The Mosaic C was 
designed as a two-context processor; it has 
two program counters and two partially 
overlapping register banks to switch in one 
clock cycle between system and user con¬ 
texts. Operations to memory are only one 
clock cycle longer than operations to 
registers. Registers are used principally as 
pointers into data structures maintained 


Cantor objects strictly 
observe the reactive 
property; they are 
normally at rest until 
a message arrives. 


by the Cantor runtime system, and are not 
saved following an object execution. 

Programming systems such as Cantor 
can also help manage the network 
resource. Direct networks exhibit paths of 
different lengths, so Cantor can place pro¬ 
cesses to balance the computing load and 
localize message traffic for communication¬ 
intensive computations. Relatively local¬ 
ized message traffic helps to reduce the 
message latency as well as the congestion 
in the communication network. The Can¬ 
tor compiler can often extract the process 
structure from the program text—so it can 
map processes systematically—or employ 
heuristics to compute a static placement 
with good properties for balancing the 
multicomputer’s communication and 
computing resources. 

Fine-grain 

concurrent programming 

For highly regular or symmetric compu¬ 
tations, such as grid-point calculations or 
systolic algorithms, we can view a fine- 
grain multicomputer as a collection of 
thousands of small computers. A second 
approach for computations with more 
complex behavior views the fine-grain 
multicomputer as a single computer. A 
partition is established between the tasks 
required of the program writer and the 
capabilities provided by the programming 
system. The program writer must express 
the computation in a way that exposes all 
of the concurrency that the system can use 
in execution. The programming system 
has complete responsibility for managing 
system resources. 

In our experiments with this second 
approach, we express computations in 
terms of fine-grain objects that communi¬ 
cate only by message-passing. The capabil¬ 


ities of objects are comparable in many 
ways to the capabilities of the processes of 
the CE/RK system. The semantics of 
message-passing are identical, but refer¬ 
ences and object creation are handled 
more carefully. An object consists of a 
code area and a private memory area. We 
have observed that the private memory 
area of objects in fine-grain message- 
driven programs is usually quite small, 
often less than one hundred bytes. 

Cantor. The Cantor programming envi¬ 
ronment consists of a compiler, runtime 
system, and other programming tools that 
together manage the concurrent resources 
of the fine-grain machine. Cantor 9 is a 
programming notation for writing 
message-driven programs using concur¬ 
rent objects. Each object is an independent 
computing agent that interacts with other 
objects solely by message-passing. The 
semantics of an object program are a form 
of Actor semantics, as defined by Agha. 8 
Each object consists of a set of private var¬ 
iables that persist between receiving mes¬ 
sages, a list of variables that describe the 
expected contents of the next message, and 
a sequence of actions that describe how the 
object will react to the next message. 

Cantor objects strictly observe the reac¬ 
tive property; they are normally at rest 
until a message arrives. An object’s 
response is determined by the contents of 
the message, the current contents of the 
private variables, and a sequence of pro¬ 
cedural statements that define the object’s 
fundamental actions, including creating 
new objects and sending more messages. 
An object in Cantor must process a mes¬ 
sage in a bounded number of steps. In 
earlier versions of Cantor, the syntax 
enforced this property. The current syntax 
has been liberalized to permit objects to 
run indefinitely; however, objects capable 
of this type of behavior can permanently 
block a computation from making 
progress. 

The composition of a node number and 
local object number produces a unique 
identifier for an object. The object iden¬ 
tifier, part of the value domain of Cantor’s 
semantics, is called a reference. Message¬ 
passing is based on the sending object’s 
possessing a reference to a destination 
object. An object acquires a reference 
upon creating a new object, or might 
receive a reference in a message. 

After the sending object completes the 
send action, the message exhibits arbitrary 
delay in traveling from sender to destina¬ 
tion. Likewise, the action of creating a new 


August 1988 


19 








object exhibits arbitrary delay. While the 
send action requires no value to be 
produced, creating a new object yields a 
reference value for the new object. Thus, 
the generation of the reference value is 
immediate and can be used in a computa¬ 
tion before the object is instantiated. For 
an object to process a message, the object 
must be instantiated. 

Flow analysis. In the implementation of 
Cantor, the decoupling between the refer¬ 


ence to an object and the instance of an 
object permits speculation about refer¬ 
ences before an object is required by a pro¬ 
gram. When the reference to an object 
exists, but the object has not yet been built, 
we call the reference value a future. Gener¬ 
ating futures prior to executing a program, 
called future flow, can improve load 
balancing and preserve locality among 
communicating objects. 

The problem of future flow during com¬ 
pilation parallels the problem of constant 


propagation in optimizing compilers. 
Value propagation graphs are constructed 
to denote the dependencies between the 
execution points where values become 
defined and the execution points where 
values are used. By generating a future for 
each of the definition vertices and 
propagating the reference value through 
the other vertices, a subset of the reference 
values used by a program is generated as 
futures at compile time. We can represent 
these futures as vertices of graphs that 


qlist (row,col: int, next: ref):: 

*[ case (cmd : sym) of 

“check” : (rn,cn : int, caller : ref) 

if rn - row or (cn - col) = abs (rn - row) 
then send (false ) to caller 
else if next = nil then send (true) to caller 

else send (“check”,rn,cn,caller) to next 
fi 
fi 

“copy” : (caller : ref) 
if next = nil 

then send (qlist(row,col,nil)) to caller 
else send (“copy”, self) to next 
[ (1: ref) send (qlist(row,col,l)) to caller ] 
fi 

] 


% dispatch on message selector 
% check for conflict 
% if row or diagonal match then 
% reply false 

% if no next then reply true 
% else test next qlist element 


°7o copy qlist 

% if last element then copy and reply 
% else forward copy request to next 
% wait for copy list and add local copy 


queen (ql: ref, cn : int, out: ref):: 

*[ (rn : int) 

send (“check”, rn, cn, self) to ql 
[ (reply : bool) 
if reply 

then send (“copy”, self) to ql 
[ (nql: ref) 
nql = qlist(rn,cn,nql) 
if cn = 8 then send (“insert”, nql) to out 

else send (1) to queen(nql, cn + 1, out) 
fi 

] 

fi 

] 

if rn < 8 then send (rn + 1) to self else exit fi 


% ql — list of valid queen positions 
% cn — column number 
% receive test row number 
% check for conflict of (rn,cn) in ql 

% if no conflict then copy ql 
<7o receive copy of ql 
% add (rn,cn) to copy of ql 
°7o if last column 
% then enqueue result 
% else search next column 


% if not last row 
% then search next row 


make_q(out: ref):: 

*[ (i: int) send (1) to queen(qlist(i,l,nil ),2,out) % make initial set 

if i < 8 then send (i +1) to self else exit fi % of 8 queen objects 

1 


Figure 10. Concurrent eight-queens program. 
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Figure 11. Object count for eight-queens (TV = °°). 


show the connectivity and genealogy of 
objects. 

The construction of the future graph is 
thwarted by data dependencies that cannot 
be resolved without running the program, 
and by nondeterminancy introduced by 
the message-passing semantics. A second 
type of flow analysis not obstructed by 
data dependencies and message nondeter¬ 
minancy predicts how an object will be 
used based on its propensity to create new 
objects and send more messages. Based on 
the semantics of message-driven pro¬ 
grams, concurrency is introduced only 
when an object sends more messages than 
it receives. The propensity to send more 
messages, called the send factor (SF ), is 
defined as the maximum number of mes¬ 
sages an object can send in response to 
processing a single message. The new fac¬ 
tor (NF) is the maximum number of new 
objects the object can create in response to 
processing a message. SFand TVFfor each 
type of object can be calculated at compile 
time. 

When creating a new object, for exam¬ 
ple, the object can generate concurrency 
(SF >1), sustain concurrency (SF =1), 
or reduce concurrency (SF < 1). If all 
objects for a program have SF < 1, then 
the program is sequential. SF and NF assist 
heuristic decisions about the placement of 
new objects. For example, if SFand NF 
are greater than one, then the new object 
should be placed on a distant node to pre¬ 
vent excessive congestion of messages and 
objects within a small patch of the host 
multicomputer. 

An example. To illustrate Cantor as a 
notation for expressing concurrent pro¬ 
grams, and to demonstrate message-driven 
programming, let us examine the “eight- 
queens” problem. The task is to place 
eight queen pieces on an 8 x 8 chessboard 
so that no queen is in jeopardy of capture. 
The queen game piece captures any other 
piece that lies along the same row, column, 
or diagonal. 

The search for the problem’s 92 solu¬ 
tions is highly concurrent. From the cap¬ 
ture rule, there will be only one queen per 
row and column. A concurrent search can 
therefore be organized either by row or by 
column. Assuming a column-by-column 
search, a queen is placed in a row of 
column 1. The rows of column 2 are then 
searched to find a safe position for the sec¬ 
ond queen. After a safe position has been 
found, the rows of column 3 are searched 
to find a safe position for the third queen. 
Each subsequent column search involves 


checking the previous row and column 
pairs to be sure that the new position is 
safe. For the case where no safe row can 
be found, the partial solution is simply dis¬ 
carded. 

A sequential search would involve back¬ 
tracking once an impossible configuration 
is exposed. The backtracking step syste¬ 
matically removes the current emplace¬ 
ments of queens and then continues with 
a new placement. For the concurrent 
search, backtracking is not necessary, 
because all solutions are equally pursued. 
The only action taken in response to a 
detected impossible configuration is to dis¬ 
card the configuration. 

The program fragment of Figure 10 per¬ 
forms the concurrent search. The names 
qlist, queen, and make_q denote object 
definitions and not objects. An object 
definition is a template for building an 
object; all objects result from object defi¬ 
nitions. A program consists of a finite 
number of object definitions used to 
generate a possibly unbounded number of 
objects. The make_q object definition 
starts the concurrent search by creating 
eight new objects using the queen defini¬ 
tion. Each of these objects searches for 
solutions starting with a different row 
number for column 1. The queen defini¬ 
tion advances the search, column by 
column. The qlist definition maintains lists 
of partial solutions. The object definitions 
for starting the program and queueing the 
answers for display are not shown. 


Performance analysis. The eight-queens 
program has been executed on sequential 
computers and such concurrent computers 
as the Cosmic Cube and Intel iPSC. The 
concurrent computers demonstrate the 
program’s concurrency by exhibiting 
decreasing time to find the 92 solutions as 
more computing nodes are applied. These 
speedup curves are not themselves very 
revealing, so an alternate approach to 
studying the dynamics of the concurrency 
defines an abstract implementation for the 
execution environment and then measures 
the utilization of different resources. 

Instrumented versions of the Cantor 
system allow a Cantor program to run 
under conditions ranging from infinite 
resources and zero latencies—the abstract 
implementation in which every opportu¬ 
nity for concurrency within a Cantor pro¬ 
gram is exploited—to specified numbers of 
nodes and message latencies. The only 
notable approximation in the measure¬ 
ments and analyses is that the processing 
of messages is assumed to be synchronized 
across all nodes. Each of these syn¬ 
chronized steps is called a sweep. Compu¬ 
tations are organized into sweeps. For each 
sweep, every node that has one or more 
messages enqueued can process one mes¬ 
sage. All of the messages sent in response 
to processing a message are produced 
together. New objects are created initially 
as messages. 

The instrumented execution of a pro¬ 
gram consists of a number of sweeps. For 
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Figure 12. Concurrency index for eight-queens (TV = °°). 
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Figure 13. Object count for eight-queens (7V=64). 
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Figure 14. Concurrency index for eight-queens (Af=64). 


each sweep the following data are 
tabulated: 

• the total number of messages, 

• the total number of active objects, 

• the total number of objects, and 

• the number of messages delivered this 
sweep. 

An active object is defined as an object 
with one or more messages queued for it. 
The total number of object executions in 
a sweep, called the concurrency index, 
equals the number of active objects under 
the abstract implementation. 

Figures 11 and 12 show the object count 
and concurrency index for the eight- 
queens program. The printing phase of the 
solutions was removed because it is 
entirely sequential. The program finds all 
92 solutions in less than 300 sweeps. The 
cost for this performance is an immodest 
number of objects, peaking out at slightly 
over 5,000. Most of these objects, how¬ 
ever, are purely transitory. The final object 
count, 830, includes the 92 solutions, 
requiring nine objects to represent each 
solution. 

The abstract implementation represents 
a best case for the execution of the eight- 
queens program. A close similarity exists 
between message-driven programs and 
event-driven simulators, in which the only 
type of event is the processing of a message 
by an object. From this correspondence we 
expect any program that behaves poorly 
under the abstract implementation to per¬ 
form poorly on any physically realizable 
implementation. 

A variation on the abstract implemen¬ 
tation fixes the number of nodes and 
evaluates program performance. Figures 

13 and 14 show the object count and con¬ 
currency index graphs for the eight-queens 
program when the number of nodes is 
limited to 64. Because the mapping 
between objects and nodes is no longer 
one-to-one, a placement algorithm must 
assign objects to nodes. The algorithm 
attempts to balance the load of objects 
across the nodes by determining the node 
with the smallest object count and then 
placing the new object on this node. 

The concurrency index graph for 64 
nodes shows that nearly all nodes are uti¬ 
lized over a large interval of sweeps. By 
limiting the number of nodes to 64, the 
time to completion is increased by a factor 
of six. Because this program is determinis¬ 
tic (in the sense of performing exactly the 
same object executions on any execution), 
the area under the curves in Figures 12 and 

14 is the same. 
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Figure 15. Comparison of message (m), object (o), and random placement (r). 


The placement algorithm used for [ 
Figures 13 and 14 required obtaining I 
global information before placing a new 
object. Figure 15 compares the perfor¬ 
mance of three placement algorithms: the 
previous algorithm (o), a variation that 
uses the message count per node instead of 
the object count (m), and random place¬ 
ment (r). The figure plots the number of 
sweeps for each of the strategies against 
the number of nodes used to execute the 
program. The horizontal dashed line 
denotes the sweep count for the abstract 
implementation. 

Random placement performs remarka¬ 
bly well and requires no global informa¬ 
tion. We can understand the performance 
of random placement by considering two 
cases. When the number of active objects 
is much smaller than the number of nodes, 
the probability that two or more objects 
are assigned to the same node is small. 
When the number of active objects is much 
greater than the number of nodes, then, by 
the weak law of large numbers, the prob¬ 
ability that a node will be assigned an 
active object increases with the number of 
assignments made. 

I n our experiments with multicom¬ 
puters over the past eight years, we 
have repeatedly underestimated their 
application span and overestimated the 
difficulty of writing programs. In fact, for 
certain applications the concurrent formu¬ 
lation for a problem has been simpler than 
the sequential formulation. Whether these 
machines will ever be considered general- 
purpose is debatable, but as message¬ 
passing performance improves relative to 
computing performance, the application 
span can only increase. 

The next challenge for the architects of 
medium-grain multicomputers is to elim¬ 
inate the software overhead of message¬ 
passing operations and to work with lan¬ 
guage and compiler developers to create 
programming environments that manage 
the system resources more completely. 

Although we see the evolution of 
medium-grain multicomputers as a low- 
risk path, we are only cautiously optimis¬ 
tic about the practicality of fine-grain 
forms of the multicomputer architecture. 
However, it is clearly time to proceed to 
the full-scale experiment. □ 
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Architecture and 
Applications of the 
Connection Machine 


Lewis W. Tucker and George G. Robertson 
Thinking Machines Corp. 


A s the use of computers affects 
increasingly broader segments of 
the world economy, many of the 
problems to which people apply com¬ 
puters grow continually larger and more 
complex. Demands for faster and larger 
computer systems increase steadily. For¬ 
tunately, the technology base for the last 
twenty years has continued to improve at 
a steady rate—increasing in capacity and 
speed while decreasing in cost for perfor¬ 
mance. However, the demands outpace 
the technology. This raises the question, 
can we make a quantum leap in perfor¬ 
mance while the rate of technology 
improvement remains relatively constant? 

Computer architects have followed two 
general approaches in response to this 
question. The first uses exotic technology 
in a fairly conventional serial computer 
architecture. This approach suffers from 
manufacturing and maintenance problems 
and high costs. The second approach 
exploits the parallelism inherent in many 
problems. The parallel approach seems to 
offer the best long-term strategy because, 
as the problems grow, more and more 
opportunities arise to exploit the parallel¬ 
ism inherent in the data itself. 

Where do we find the inherent parallel¬ 
ism and how do we exploit it? Most com¬ 
puter programs consist of a control 
sequence (the instructions) and a collection 
of data elements. Large programs have 
tens of thousands of instructions operat- 



Massively parallel 
computer architectures 
have come of age. We 
describe here the 
architecture, evolution, 
and applications of 
the Connection 
Machine system. 


ing on tens of thousands or even millions 
of data elements. We can find opportuni¬ 
ties for parallelism in both the control 
sequence and in the collection of data 
elements. 

In the control sequence, we can identify 
threads of control that could operate 
independently, thus on different proces¬ 
sors. This approach, known as control 
parallelism, is used for programming most 
multiprocessor computers. The primary 
problems with this approach are the diffi¬ 


culty of identifying and synchronizing 
these independent threads of control. 

Alternatively, we can take advantage of 
the large number of independent data ele¬ 
ments by assigning one processor to each 
data element and performing all opera¬ 
tions on the data in parallel. This 
approach, known as data parallelism ,' 
works best for large amounts of data. For 
many applications, it proves the most nat¬ 
ural programming approach, leading to 
significant decreases in execution time as 
well as simplified programming. 

Massively parallel architectures contain¬ 
ing tens of thousands or even millions of 
processing elements support this “data- 
parallel” programming model. Early 
examples of this kind of architecture are 
ICL’s Distributed Array Processor 
(DAP), 2 Goodyear’s Massively Parallel 
Processor (MPP), 3 Columbia Univer¬ 
sity’s Non-Von, 4 and others. 5 Each of 
these machines has some elements of the 
desired architecture, but lacks others. For 
example, the MPP has 16K (K = 1,024) 
processing elements arranged in a two- 
dimensional grid, but interprocessor com¬ 
munication is supported only between 
neighboring processors. 

The Connection Machine provides 64K 
physical processing elements, millions of 
virtual processing elements with its virtual 
processor mechanism, and general- 
purpose, reconfigurable communications 
networks. The Connection Machine 
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Figure 1. Connection Machine system organization. 


encompasses a fully integrated architec¬ 
ture designed for data-parallel computin g. 

Architecture of the 
Connection Machine 

The Connection Machine is a data- 
parallel computing system with integrated 
hardware and software. Figure 1 shows the 
hardware elements of the system. One to_ 
four front-en d computer syste ms (right 
sideln figure" 1) provide the development 
and execution environments for system' 
software. They connect through the nexus 
(a 4 x 4 cross-point switch) to trom one to 


four sequence rs. Each sequencer contro ls 
up to 16,384 individual processors execut¬ 
ion! parallel operations. A high- 
performance, data-parallel I/O system 
(bottom of Figure 1) connects processors 
to peripheral mass storage (the DataVault) 
and graphic display devices? 

System software is based upon the oper¬ 
ating system or environment of the front- 
end computer, with minimal visible soft¬ 
ware extensions. Users can program using 
familiar languages and programming con¬ 
structs, with all development tools 
provided by the front end. Programs have 
normal sequential control flow and do not 
need new synchronization structures. 


Thus, users can easily develop programs 
that exploit the power of the Connection 
Machine hardware. 

At the heart of the Connection Machine 
system lies the parallel-processing unit 
consisting of thousands of processors (up 
to 64K), each with thousands of bits of 
memory (four kilobits on the CM-1 and 64 
kilobits on the CM-2). As well as process¬ 
ing the data stored in memory, these 
processors when logically interconnected 
can exchange information. All operations 
happen in parallel on all processors. Thus, 
the Connection Machine hardware directly 
supports the data-parallel programming 
model. 
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Figure 3. Complex problems change topology. 


CM-1: First implementation of CM 
concept. Hillis originally conceived the 
Connection Machine architecture while at 
MIT and described it in his thesis. 6 The 
design of the Connection Machine began 


in 1980 at the MIT AI Laboratory, where 
the basic architectural design and proto¬ 
type custom integrated circuits were devel¬ 
oped. It became clear that private 
enterprise would have to get involved to 


actually build the machine, so Thinking 
Machines was founded in 1983. 

The Connection Machine Model CM-1 
was designed at Thinking Machines dur¬ 
ing 1983 and the first half of 1984. By the 
end of 1984, with funding from the 
Defense Advanced Research Projects 
Agency, Thinking Machines had built the 
first 16K-processor CM-1 prototype. A 
demonstration of its capabilities took 
place in May 1985, and by November the 
company had constructed and successfully 
demonstrated a full 64K-processor 
machine. Thinking Machines commer¬ 
cially introduced the machine in April 
1986. The first machines went to MIT and 
Perkin-Elmer in the summer of 1986. 

As illustrated in Figure 1, the CM-1 con¬ 
tains the following system components: 

• up to 64K data processors, 

• an interprocessor communications 
network, 

• one to four sequencers, and 

• one to four front-end computer 
interfaces. 

Although part of the original Connec¬ 
tion Machine design, the I/O system was 
not implemented until the introduction of 
the CM-2. 

CM-1 data processors and memory. The 
CM-1 parallel-processing unit contains 
from 16K to 64K data processors. As 
shown in Figure 2, each data processor 
contains 

• an arithmetic-logic unit and 
associated latches, 

• four kilobits of bit-addressable 
memory, 

• eight one-bit flag registers, 

• a router interface, and 

• a two-dimensional-grid interface. 

The data processors are implemented 

using two chip types. A proprietary cus¬ 
tom chip contains the ALU, flag bits, and 
communications interface for 16 data 
processors. Memory consists of commer¬ 
cial static RAM chips, with parity protec¬ 
tion. A fully configured parallel-processing 
unit contains 64K data processors, consist¬ 
ing of 4,096 processor chips and 32 mega¬ 
bytes of RAM. 

A CM-1 ALU consists of a three-input, 
two-output logic element and associated 
latches and memory interface (see Figure 
2). The basic conceptual ALU cycle first 
reads two data bits from memory and one 
data bit from a flag. The logic element then 
computes two result bits from the three 
input bits. Finally, one of the two results 
is stored in memory and the other result, 
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in a flag. The entire operation is condi¬ 
tional on the value of a context flag; if the 
flag is zero, then the results for that data 
processor are not stored. 

The logic element can compute any two 
Boolean functions on three inputs. This 
simple ALU suffices to carry out all the 
operations of a virtual-machine instruc¬ 
tion set. Arithmetic is carried out in a bit- 
serial fashion, requiring 0.75 microsecond 
per bit plus instruction decoding and over¬ 
head. Hence, a 32-bit Add takes about 24 
microseconds. With 64K processors com¬ 
puting in parallel, this yields an aggregate 
rate of 2,000 million instructions per sec¬ 
ond (that is, two billion 32-bit Adds per 
second). 

The CM_ processing element is a 

reduced-instruction-set-computer proces - 
sor. Each ALU cycle breaks down into 
subcycles. On each cycle, data processors 
execute one low-level instruction (called a 
nanoinstruction ) issued by the sequencer, 
while the memories can perform one read 
or write operation. The basic ALU cycle 
for a two-operand integer Add consists of 
three nanoinstructions: LoadA to read 
memory operand A, LoadB to read mem¬ 
ory operand B, and Store to store the result 
of the ALU operation. Other nanoinstruc¬ 
tions direct the router and NEWS (north¬ 
east-west-south) grid, and perform diag¬ 
nostic functions. 

CM-1 communications. Algorithm 
designers typically use data structuring 
techniques to express important relation¬ 
ships between data elements. For example, 
an image-understanding system usually 
employs a two-dimensional grid to repre¬ 
sent the individual pixels of the image. At 
a later stage in the processing, however, a 
tree data structure or relational graph 
might represent more abstract relation¬ 
ships such as those between objects and 
their parts (see Figure 3). _ 

On a serial machine with sufficient ran¬ 
dom access memory, pointers to memory 
elements are used to implement complex 
data structures .Jn a data-parallel architec ¬ 
ture. however, individual data eleme nts 
are assigned to individual processors and 
mterprocessor communication expresses 

tne relationships between t he elements of 
Je ry l ar ge data s tructure sT - -- 

The cKFl was"3esigned with flexible 
interprocessor communication in mind 
and supports several distinct communica¬ 
tion mechanisms: 


The CM-1 was 
designed with flexible 
interprocessor 
communication 
in mind. 


front-end computer or the sequencer to all 
data processors at once. 

• Global OR is a logical OR of the ALU 
carry output from all data processors, 
which makes it possible to quickly discover 
unusual or termination conditions. 

• Hypercube communication forms the 
basis for the router and numerous paral¬ 
lel primitives supported by the virtual- 
machine model. The topology of the net¬ 
work consists of a Boolean «-cube. For a 
fully configured CM-1, the network is a 
12-cube connecting 4,096 processor chips 
(that is, each 16-processor chip lies at the 
vertex of a 12-cube). An example of a par¬ 
allel primitive implemented with the 
Hypercube is Sort, which runs in logarith¬ 
mic time; sorting 64K 32-bit keys takes 
about 30 milliseconds. 

• The router directly implements 
general pointer following with switched 
message packets containing processor 
addresses (the pointers) and data. The 
router controller, implemented in the CM 
processor chips, uses the Hypercube for 
data transmission. It provides heavily 
overlapped, pipelined message switching 
with routing decisions, buffering, and 
combining of messages directed to the 
same address, all implemented in 
hardware. 

• The NEWS grid is a two-dimensional 
Cartesian grid that provides a direct way 
to perform nearest-neighbor communica¬ 
tion. Since all processors communicate in 
the same direction (north, east, west, or 
south), addresses are implicit and no col¬ 
lisions occur, making NEWS communica¬ 
tion much faster (by about a factor of six) 
than router communication for simple 
regular message patterns. 


• Broadcast communications allow CM-1 sequencer, nexus, and front-end 
immediate data to be broadcast from the interface. The CM-1 sequencer—a spe¬ 


cially designed microcomputer used to 
implement the CM virtual machine—is 
implemented as an Advanced Micro 
Devices 2901/2910 bit-sliced machine with 
16K 96-bit words of microcode storage. A 
Connection Machine contains from one to 
four sequencers. The sequencer’s input is 
a stream of high-level, virtual-machine 
instructions and arguments, transmitted 
on a synchronous 32-bit parallel data path 
from the nexus. The sequencer outputs a 
stream of nanoinstructions that controls 
the timing and operation of the CM data 
processors and memory. 

The CM-1 nexus—a 4x4 cross-point 
switch—connects from one to four front- 
end computers to from one to four 
sequencers. The connections to front-end 
computers are via high-speed, 32-bit, par¬ 
allel, asynchronous data paths, while the 
connections to sequencers are syn¬ 
chronous. The nexus provides a partition¬ 
ing mechanism so that the CM can be 
configured as up to four partitions under 
front-end control. This allows isolation of 
parts of the machine for different users or 
purposes (such as diagnosis and repair of 
a failure in one partition while other par¬ 
titions continue to run). When more than 
one sequencer is connected to the same 
front-end through the nexus, they are syn¬ 
chronized by a common clock generated 
by the nexus. 

The front-end bus interface supports a 
32-bit, parallel, asynchronous data path 
between the front-end computer and the 
nexus. The FEBI is the only part of the 
CM-1 that lies outside of the main cabinet. 
It resides as a board in the system bus of 
the front end (any DEC VAX containing 
a VAXBI I/O bus and running Ultrix, or 
any Symbolics 3600 series Lisp machine). 

CM virtual-machine model. The CM 
virtual-machine parallel instruction set, 
called Paris, presents the user with an 
abstract machine architecture very much 
like the physical Connection Machine 
hardware architecture, but with two 
important extensions: a much richer 
instruction set and a virtual-processor 
abstraction. 

Paris. Paris provides a rich set of paral¬ 
lel primitives ranging from simple arith¬ 
metic and logical operations to high-level 
APL-like reduction (parallel prefix) oper¬ 
ations, 7 sorting, and communications 
operations. The interface to Paris between 
the front end and the rest of the Connec¬ 
tion Machine reduces to a simple stream of 
operation codes and arguments. The argu- 
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Figure 4. Conneclion Machine Model CM-2 and DataVault. 


ments usually describe fields to operate on, 
in the form of a start address and bit 
length. Arguments can also be immediate 
data, broadcast to all data processors. 

Most of Paris is implemented in firm¬ 
ware and runs on the sequencers, where 
the opcode/argument stream is parsed and 
expanded to the appropriate sequence of 
nanoinstructions for the data processors. 
Since Paris defines the virtual-machine 
instruction set, we use the same name for 
the assembly language of the Connection 
Machine. 

Virtual processors. Data-parallel appli¬ 
cations often call for many more individ¬ 
ual processors than are physically available 
on a given machine. Connection Machine 
software provides for this through its 
virtual-processor mechanism, supported 
at the Paris level and transparent to the 
user. When we initialize the Connection 
Machine system, the number of virtual 
processors required by the application is 
specified. If this number exceeds the num¬ 
ber of available physical processors, the 
local memory of each processor splits into 
as many regions as necessary, with the 
processors automatically time-sliced 
among the regions. 

For example, if an application needed to 
process a million pieces of data, it would 


request F = 2 20 virtual processors. 
Assume the available hardware to have 
P=2 16 physical processors, each with 
M = 2 16 bits of memory (the size for CM-2 
memory; M = 2 12 bits of memory for the 
CM-1). Then each physical processor 
would support V/P —16 virtual 
processors. 

This ratio V/P, usually denoted N, is 
called the virtual-processor ratio, or VP- 
ratio. In this example, each virtual proces¬ 
sor would have M/N = 2 12 bits of mem¬ 
ory and would appear to execute code at 
about l/N = 1/16 the speed of a physical 
processor. In fact, virtual processors often 
exceed this execution rate, since instruc¬ 
tion decoding by the sequencer can be 
amortized over the number of virtual 
processors. 

CM software environment. The Con¬ 
nection Machine system software uses 
existing programming languages and envi¬ 
ronments as much as possible. Languages 
are based on well-known standards. Min¬ 
imal extensions support data-parallel con¬ 
structs so that users need not learn a new 
programming style. The Connection 
Machine front-end operating system 
(either Unix or Lisp) remains largely 
unchanged. 

Fortran on the Connection Machine 


system uses the array extensions in the 
draft Fortran 8x standard (proposed by 
American National Standards Institute 
Technical Committee X3J3) to express 
data-parallel operations. The remainder of 
the language is the standard Fortran 77. 
No extension is specific to the Connection 
Machine; the Fortran 8x array extensions 
map naturally onto the underlying data- 
parallel hardware. 

The *Lisp and CM-Lisp languages are 
data-parallel dialects of Common Lisp (a 
version of Lisp currently being stan¬ 
dardized by ANSI Technical Committee 
X3J13). *Lisp gives programmers fine 
control over the CM hardware while main¬ 
taining the flexibility of Lisp. CM-Lisp is 
a higher-level language that adds small 
syntactic changes to the language interface 
and creates a powerful data-parallel pro¬ 
gramming language. 

The C * language is a data-parallel exten¬ 
sion of the C programming language (as 
described in the draft C standard proposed 
by ANSI Technical Committee X3J11). 
C * programs can be read and written like 
serial C programs. The extensions are 
unobtrusive and easy to learn. 

The assembly language of the Connec¬ 
tion Machine, Paris, is the target language 
of the high-level-language compilers. Paris 
logically extends the instruction set of the 
front end and masks the physical imple¬ 
mentation of the CM processing unit. 

Evolution of the CM-2. Experience 
gained during the first year of in-house use 
of the CM-1 led to the initiation of a proj¬ 
ect to build an improved version of the 
machine: the Connection Machine Model 
CM-2. 

The design team established several 
goals for the CM-2: increasing memory 
capacity, performance, and overall relia¬ 
bility while maintaining or improving ease 
of manufacturing. To continue to support 
the CM-1 customer base, the designers 
wanted the CM-2 to be program compat¬ 
ible with the previous machine. Finally, 
the designers wanted the CM-2 to incor¬ 
porate a high-speed I/O system for 
peripheral data storage and display 
devices. 

To satisfy these goals, CM-2 kept the 
basic architecture of the CM-1 (see Figure 
1). To increase performance, the CM-2 
incorporates a redesigned sequencer and 
CM processor chip and an optional 
floating-point accelerator. A four-fold 
increase in microcode storage in the 
sequencer allowed for improvements in 
performance and functionality in the 
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virtual-machine implementation. A 
sixteen-fold increase in memory capacity 
brought total memory capacity up to 512 
megabytes. Enhanced reliability resulted 
from adding error correction to the mem¬ 
ory system, and diagnostic capability was 
improved by increasing the number of 
data paths with error detection (parity). A 
redesigned NEWS grid increased function¬ 
ality and ease of manufacture. CM-2 
implemented an I/O system to support a 
massively parallel disk system (called the 
DataVault) and a high-speed color 
graphics system. 

The CM processor chip underwent rede¬ 
sign in late 1985 and early 1986. The first 
prototype of the CM-2 was working by the 
end of 1986. The company commercially 
introduced the CM-2 (see Figure 4) in April 
1987, and delivered about a dozen 
machines to customers in the fall of 1987. 
The first DataVault was delivered at the 
end of 1987. 

CM-2 data processors and memory. The 
CM-2 data processor strongly resembles 
the CM-1 data processor. The major 
differences are 

• 64 kilobits of bit-addressable memory 
instead of four kilobits, 

• four one-bit flag registers instead of 
eight, 

• an optional floating-point accelerator, 

• a generalized NEWS-grid interface to 
support n -dimensional grids, 

• an I/O interface, and 

• increased error-detection circuitry. 

The CM-2 data processors are imple¬ 
mented using four chip types. A proprie¬ 
tary custom chip contains the ALU, flag 
bits, router interface, NEWS-grid inter¬ 
face, and I/O interface for 16 data proces¬ 
sors, and part of the Hypercube network 
controller. The memory consists of com¬ 
mercial dynamic RAM chips, with single¬ 
bit error correction and double-bit error 
detection. The floating-point accelerator 
consists of a custom floating-point inter¬ 
face chip and a floating-point execution 
chip; one of each is required for every 32 
data processors. A fully configured 64K- 
processor system contains 4,096 processor 
chips, 2,048 floating-point interface chips, 
2,048 floating-point execution chips, and 
half a gigabyte of RAM. 

CM-2 floating-point accelerator. In 
addition to the bit-serial data processors 
described above, the CM-2 parallel¬ 
processing unit has an optional floating¬ 
point accelerator closely integrated with 
the processing unit. This accelerator has 
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transfer rates for large 
blocks of data. 


two options: single precision or double 
precision. Both options support IEEE 
standard floating-point formats and oper¬ 
ations, and increase the rate of floating¬ 
point calculations by a factor of more than 
20. Taking advantage of this speed 
increase requires no change in user 
software. 

The hardware associated with each of 
these options consists of two special- 
purpose very-large-scale-integration chips: 
a memory-interface unit and a floating¬ 
point execution unit for each pair of CM-2 
processor chips. Because the floating¬ 
point units access memory in an 
orthogonal manner to the CM-2 proces¬ 
sors, the memory-interface unit transposes 
32-bit words before passing them to the 
floating-point unit. 

Firmware that drives the floating-point 
accelerator stages the data through the 
memory-interface unit to the floating¬ 
point execution unit. In general, it takes 
5 A stages to implement a floating-point 
operation, for a virtual-processor ratio of 
A. However, the firmware is pipelined so 
as to require only 3 A + 2 stages instead of 
5 A stages. 

CM-2 communications. The CM-2 
communications are basically the same as 
those of the CM-1 with two exceptions. 
First, we redesigned the router to improve 
reliability, diagnostic capability, and per¬ 
formance. For example, we enhanced its 
performance by providing hardware for 
en route combining of messages directed 
to the same destination. The combining 
operations supported include Sum, Logi¬ 
cal OR, Overwrite, Max, and Min. 

The second major difference lies in the 
nature of grid communications. We com¬ 
pletely redesigned grid communications 
for the CM-2. We wanted to increase flex¬ 
ibility and functionality while simplifying 
the overall system architecture and 
increasing manufacturing ease and relia¬ 


bility. We accomplished this by replacing 
the two-dimensional NEWS grid with a 
more general n -dimensional grid imple¬ 
mented on top of the Hypercube (by grey¬ 
encoding addresses). We enhanced flexi¬ 
bility and functionality by supporting 
high-level-language concepts with n- 
dimensional-grid nearest-neighbor com¬ 
munication. Thus, programmers can 
employ one-dimensional to sixteen¬ 
dimensional nearest-neighbor grid com¬ 
munication according to the requirements 
of the task. Manufacturing ease and relia¬ 
bility are enhanced because we removed 
the separate set of cables for the NEWS 
grid. 

CM-2 I/O structure. The Connection 
Machine I/O structure moves data into or 
out of the parallel-processing unit at 
aggregate peak rates as high as 320 mega¬ 
bytes per second using eight I/O con¬ 
trollers. All transfers are parity-checked 
on a byte-by-byte basis. 

A Connection Machine I/O bus runs 
from each I/O controller to the devices it 
controls. This bus is 80 bits wide (64 data 
bits, eight parity bits, and eight control 
bits). The I/O controller multiplexes and 
demultiplexes between 256-bit processor 
chunks and 64-bit I/O-bus chunks. The 
controller also acts as arbitrator, allocat¬ 
ing bus access to the various devices on the 
bus. 

DataVault. Since standard peripheral 
devices do not operate at the speeds that 
the CM system itself can sustain, we had 
to design a mass-storage system capable of 
operating at very high speed. The 
DataVault combines high reliability with 
fast transfer rates for large blocks of data. 
It holds five gigabytes of data, expanda¬ 
ble to ten gigabytes, and transfers data at 
a rate of 40 megabytes per second. Eight, 
DataVaults, operating in parallel, offer a 
combined data transfer rate of 320 mega¬ 
bytes per second and hold up to 80 giga¬ 
bytes of data. 

The design philosophy followed for the 
Connection Machine architecture served 
for the DataVault as well: we used stan¬ 
dard technology in a parallel configura¬ 
tion. Each DataVault unit stores data 
spread across an array of 39 individual 
disk drives. Each 64-bit data chunk 
received from the Connection Machine 
I/O bus is split into two 32-bit words. 
After verifying parity, the DataVault con¬ 
troller adds seven bits of error-correcting 
code and stores the resulting 39 bits on 39 
individual drives. Subsequent failure of 
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Table 1. Example applications. 


Field 

Application 

Geophysics 

Modeling geological strata using reverse time 
migration techniques 

VLSI Design 

Circuit simulation and optimization of cell place¬ 
ment in standard cell or gate array circuits 

Particle Simulation 

N-body interactions, such as modeling defect 
movement in crystals under stress and modeling 
galaxy collisions 

Fluid-Flow Modeling 

Cellular autonoma and Navier-Stokes-based 
simulation, such as turbulance simulation in 
helicopter rotor-wake analysis and fluid flow 
through pipes 

Computer Vision 

Stereo matching, object recognition, and image 
processing 

Protein-Sequence Matching 

Large database searching for matching protein 
sequences 

Information Retrieval 

Document retrieval from large databases, analysis 
of English text, and memory-based reasoning 

Machine Learning 

Neural-net simulation, conceptual clustering, 
classifier systems, and genetic algorithms 

Computer Graphics 

Computer-generated graphics for animation and 
scientific visualization 


any one of the 39 drives does not impair 
reading of the data, since the ECC allows 
detection and correction of any single-bit 
error. 

Although operation is possible with a 
single failed drive, three spare drives can 
replace failed units until repaired. The 
ECC provides 100-percent recovery of the 
data on the failed disk, allowing a new 
copy of this data to be reconstructed and 
written onto the replacement disk. Once 
this recovery is complete, the database is 
considered healed. This mass-storage sys¬ 
tem architecture leads to high transfer 
rates, reliability, and availability. 

Graphics display. Visualization of scien¬ 
tific information is becoming increasingly 
important in areas such as modeling fluid 
flows or materials under stress. The enor¬ 
mous amount of information resulting 
from such simulations is often best com¬ 
municated to the user through high-speed 
graphic displays. We therefore designed a 
real-time, tightly coupled graphic display 
for the Connection Machine. This system 
consists of a 1,280 x 1,024-pixel frame- 
buffer module with 24-bit color and four 
overlays (with hardware pan and zoom) 


and a high-resolution, 19-inch color mon¬ 
itor. The frame buffer is a single module 
that resides in the Connection Machine 
backplane in place of an I/O controller. 
This direct backplane connection allows 
the frame buffer to receive data from the 
Connection Machine processors at rates 
up to one gigabit per second. 

CM-2 engineering and physical charac¬ 
teristics. The cube-shaped Connection 
Machine measures 1.5 meters a side and is 
made up of eight subcubes. Each subcube 
contains 16 matrix boards, a sequencer 
board, and two I/O boards, arranged ver¬ 
tically. This vertical arrangement allows 
air cooling of the machine. Power dissipa¬ 
tion is 28 kilowatts. Each matrix board has 
512 processors and four megabytes of 
memory. The matrix board has 32 custom 
chips implementing the processors and 
router, 16 floating-point chips, 16 custom 
floating-point memory-interface chips, 
and 176 RAM chips. The nexus board 
occupies the space between the subcubes. 
Each front end has one front-end interface 
board. Red lights on the front and back, 
with one light for each CM chip (4,096 
altogether), assist troubleshooting. 


Conservative engineering throughout 
ensures that the machine is manufactura¬ 
ble, maintainable, and reliable. The power 
of the machine arises from its novel archi¬ 
tecture rather than from exotic engineer¬ 
ing. It incorporates few types of boards; 
one board in particular—the matrix 
board—is replicated 128 times in a 64K 
machine. The matrix board is a 10-layer 
board with 9-mil trace widths. 

The chip technology is also current state 
of the art and conservative. The CM-1 chip 
was implemented on a 10,000-gate, two- 
micron, complementary-metal-oxide- 
semiconductor gate array. The CM-2 chip 
is implemented on two-micron CMOS 
standard cells and has about 14,000 gate 
equivalents. 

The massive parallelism of the machine 
makes it possible to provide a particularly 
powerful and fast set of hardware diagnos¬ 
tics. For example, the entire memory 
(which accounts for a large percentage of 
the silicon area of the machine) can be 
tested in parallel. Diagnostics can isolate 
a failure to a particular chip or pair of 
chips and one wire connecting them more 
than 98 percent of the time. Diagnostics, 
in combination with the error-detection 
hardware on all data paths, leads to a relia¬ 
ble and maintainable system, with mean 
time to repair well under one hour. 

CM-2 performance. We can measure 
the Connection Machine’s performance in 
a number of ways. Since the machine uses 
bit-serial arithmetic, the speed of integer 
arithmetic and logical operations will vary 
with word length; the languages imple¬ 
mented on the machine take advantage of 
this and use small fields whenever possible. 
For example, 32-bit integer arithmetic and 
logical operations run at 2,500 million 
instructions per second, while eight-bit 
arithmetic runs at 4,000 MIPS. 

The speed of the machine also depends 
on how many processors take part in a par¬ 
ticular calculation, and on the virtual- 
processor ratio. In some cases, higher 
virtual-processor ratios lead to higher 
instruction rates because the physical 
processors are better utilized. 

Sustained floating-point performance 
has been shown to exceed 20 gigaflops (bil¬ 
lions of floating-point operations per sec¬ 
ond) for polynomial evaluation using 
32-bit floating-point-precision operands. 
When the function to be computed 
involves interprocessor communication 
such as a 4K x 4K-element matrix multi¬ 
ply, sustained performance typically 
exceeds five gigaflops. 
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We can express the performance of the 
Connection Machine communications sys¬ 
tems in either of two ways: bandwidth or 
time per operation. Grid communications 
performance varies with the choice of grid 
dimensionality, grid shape, and virtual- 
processor ratio. A two-dimensional-grid 
Send operation takes about three microse¬ 
conds per bit. For 32-bit, two-dimensional 
grid operations, that translates into 96 
microseconds or 20 billion bits per second 
of communications bandwidth. 

Router communications performance is 
somewhat harder to measure because it 
depends on the complexity of the address¬ 
ing pattern in the message mix, and thus 
the number of message collisions. For t a 
typical message mix, 32-bit general Send 
operations take about 600 microseconds. 
This translates into about three billion bits 
per second of communications bandwidth 
for typical message mixes (peak bandwidth 
exceeds 50 billion bits per second). 

The performance of the Connection 
Machine I/O system depends on the num¬ 
ber of channels in use. Each of up to eight 
I/O channels has a bandwidth of 40 mil¬ 
lion bytes per second, for a total band¬ 
width of 320 million bytes per second. This 
peak bandwidth has been observed on an 
installed DataVault disk system. The typi¬ 
cal sustained bandwidth on the DataVault 
is 210 million bytes per second, which 
makes it possible to copy the entire con¬ 
tents of the Connection Machine memory 
(512 megabytes) to disk in about 2.4 
seconds. 

The preceding discussions show that the 
Connection Machine achieves significant 
gains in performance over conventional 
computers through the use of a data- 
parallel model in a fine-grained, massively 
parallel architecture without using any 
exotic technology. But, how broadly 
applicable is this data-parallel model? In 
the remainder of this article, we will illus¬ 
trate the breadth of applications by 
describing a range of applications already 
developed on the Connection Machine. 


Applications of the 
Connection Machine 

Performance measures of massively 
parallel architectures tell only part of the 
story. One of the significant revelations 
that occurred with the introduction of the 
Connection Machine concerned the sur¬ 
prising number of different application 
areas suitable for this technology. 


The general-purpose 
nature of the 
Connection Machine 
permits it to be 
applied equally well to 
numeric and 
symbolic processing. 


Although data-parallel programming 
requires a different approach towards 
computation, programmers quickly 
adapted. In fact, they often found that 
many systems are naturally expressed in a 
data-parallel programming model. Fears 
that parallel programming would require 
a massive reeducation effort proved 
unfounded. 

The partial list of applications given in 
Table 1 illustrates the range of applications 
developed for the Connection Machine. In 
general, most applications required less 
than a person-year of effort and were pro¬ 
totyped in a matter of months. The list 
includes examples from engineering, 
materials science, geophysics, artificial 
intelligence, document retrieval, and com¬ 
puter graphics. Far from being an archi¬ 
tecture designed for special domains, the 
general-purpose nature of the Connection 
Machine permits it to be applied equally 
well to numeric and symbolic processing. 

We include here discussions of three 
applications from the fields of VLSI 
design, materials science, and computer 
vision. These examples illustrate the use of 
parallelism in a range of areas and the role 
interprocessor communication plays in 
supporting the data-structure require¬ 
ments of each application. Grid-based 
communication finds primary application 
in regularly structured problems such as 
particle simulations, while general routing 
supports the differing topologies of circuit 
simulation and computer vision. 

Consult Waltz 8 for detailed descrip¬ 
tions of several other applications. 

Molecular dynamics. Since the 1960s, 
materials science has been a key technol¬ 
ogy in designing jet-engine turbine blades 
and other high-technology products. To 


understand materials more fully, designers 
often perform simulation studies. Unfor¬ 
tunately, macro-level experiments, 
whether direct or computer-simulated, 
have not successfully explained important 
behaviors such as metal fatigue. That 
requires simulation at the molecular level. 
Here a major problem arises. Studies of 
perfect crystals generally offer little help 
in understanding real-world materials, as 
evidenced by the fact that the strengths 
predicted by such studies often exceed 
those measured in actual metals by twenty 
to fifty times. Defects in the crystalline 
structure alter its properties and dramati¬ 
cally increase the computational complex¬ 
ity of simulation studies. Often the 
interactions of ten thousand to one million 
atoms need to be simulated to accurately 
represent the real-world behavior of 
materials. 

Molecular-dynamics simulation is 
extremely computation-intensive, and the 
necessity of computing high-order interac¬ 
tions on systems of millions of particles 
poses major problems for conventional 
machines. Data-parallel architectures per¬ 
mit the investigator to see in minutes what 
would take hours on traditional hardware. 
The Connection Machine virtual- 
processor mechanism allows the investiga¬ 
tor to simulate systems many times larger 
than would a physical-processor system 
alone. 

A commonly used model for molecular 
dynamics uses the Lennard-Jones 6/12 
potential to describe the interactions 
between uncharged, nonbonded atoms. 
Two approaches permit the study of this 
behavior on the Connection Machine. In 
both cases, processors are assigned to indi¬ 
vidual particles. Each processor contains 
the (x,y,z) position of the particle, the 
velocity, and the force on the particle from 
a previous time step of the simulation. All 
calculations are performed using 32-bit 
floating-point precision. 

In the first approach, we consider inter¬ 
actions between all particles. Particles are 
arbitrarily assigned to processors. The 
NEWS grid circulates the information 
about each particle throughout the CM 
such that each processor can compute the 
force its particle receives from every other 
particle in the system. All processors use 
the result of these forces to update their 
own (x,y,z) position in parallel. Depend¬ 
ing upon the purpose of the simulation, we 
might observe several hundred time steps. 
For large systems, each processor com¬ 
putes tens of thousands of force calcula¬ 
tions during a single time step. 
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Figure 5. VLSI cell placement. Given an 
initial placement of cells, individual 
cells swap positions to reduce the total 
wire length. 


This approach makes no assumption 
about which particles lie near others and 
hence dominate the overall force calcula¬ 
tion. Dramatic improvements in execution 
time are possible if we know the location 
of nearby particles in advance. If we 
assume that the particles of the simulation 
have a regular structure and do not drift 
far from their initial relative positions (as 
in modeling solid-phase materials at low 
temperatures), we can take an alternative 
approach. 

In the second approach, particles are 
assigned to processors according to their 
spatial configuration. In a manner akin to 
convolution, nearest-neighbor communi¬ 
cation is used to calculate the forces from 
a surrounding KxK neighborhood of 
particles. Particles are free to drift, but we 
assume they stay roughly ordered relative 
to each other. Since the force calculation 
is dominated by these near neighbors, we 
can impose a cutoff in the force calcula¬ 
tion. We simply ignore interactions of dis¬ 
tant particles. 

Even in large-scale simulations, the 
number of near neighbors remains rela¬ 
tively small. Thus, we need to compute 
only a fraction of the total number of force 
calculations. As expected, this results in a 
significant reduction in the time required 
for simulation. Systems as large as a mil¬ 
lion molecules when tested showed sus¬ 
tained execution rates in excess of 2.6 
gigaflops. 


Researchers have applied this data- 
parallel approach to studying defect 
motion in two-dimensional crystals of 
16,384 atoms. They introduce stress by 
gradually shifting the top and bottom rows 
of atoms in opposite directions. They then 
observe the resulting movement, or perco¬ 
lation, of the defects. This work has con¬ 
tributed greatly to the study of 
stress-failure modes in various materials. 


VLSI design and circuit simulation. 

Computer-aided design tools are routinely 
used in VLSI design, but as the size of cir¬ 
cuits increases, two aspects of the design 
process become increasingly important 
and computationally expensive: cell place¬ 
ment and circuit simulation. 

Cell placement. Semicustom VLSI cir¬ 
cuits with more than 10,000 cells or parts 
have become quite common. Placing this 
number of parts on a chip while simultane¬ 
ously minimizing the area taken up by 
interconnecting wire has proved a difficult 
and time-consuming problem. Minimiza¬ 
tion of area occupied is important because 
in general the smaller the area, the higher 
the expected yield. Designers have applied 
various automated methods to this prob¬ 
lem. One method, employing simulated 
annealing, 9 produces good optimization 
results on a broad spectrum of placement 
problems. Unfortunately, for circuits hav¬ 
ing 15,000 parts, simulated annealing may 
require 100 to 360 hours on a conventional 
computer. On a 64K-processor Connec¬ 
tion Machine, the time required reduces to 
less than two hours. 

Simulated annealing is an optimization 
procedure related to an analogous process 
in materials science wherein the strength of 
a metal is improved by first raising it to a 
high temperature and then allowing it to 
cool slowly. When the metal is hot, the 
energy associated with its molecules causes 
them to roam widely. As the metal cools, 
molecules lose their energy and become 
more restricted in their movements, set¬ 
tling into a compact, stable configuration. 
This general optimization procedure, 
already applied to a variety of problems, 
supports parallel implementation. 

Designers apply simulated annealing to 
VLSI placement in the following way. 
Given an initial arbitrary placement of 
cells for a VLSI circuit, the designer first 
computes the size of the silicon chip 
required. Improvement in the layout 
results from swapping cells to reduce the 
total wire length (see Figure 5). If the only 


exchanges permitted are those that reduce 
total wire length, the placement pattern 
would seek a local minimum—not neces¬ 
sarily optimal. 

Simulated annealing, however, accepts 
a certain percentage of “bad” moves in 
order to expose potentially better solu¬ 
tions, avoiding the classic trap of local 
minimums. The percentage of such “bad” 
moves the system will accept is governed 
by a parameter usually expressed as a tem¬ 
perature. Starting with a high tempera¬ 
ture, a large number of cells are permitted 
to change position over great distances. 
Gradually, the temperature parameter is 
lowered, restricting the movement of cells 
and the number of exchanges. Ultimately, 
the system converges to a near-optimal 
solution as only nearby “good” exchanges 
are permitted. 

Implementation of simulated annealing 
in parallel on the Connection Machine is 
straightforward. Individual cells, potential 
locations for cells, and nodes where wires 
between cells connect are represented in 
individual processors. The need to 
exchange information between cells at 
arbitrary locations illustrates the utility of 
the general router-based communications 
mechanism of the Connection Machine. 

Simulated annealing takes place as fol¬ 
lows. According to the given temperature 
parameter, a certain percentage of cells 
initiate a swap, calculate the expected 
change in wire length, and accept or reject 
the move. Potential exchanges are chosen 
by randomly generating the addresses of 
other cells. (Exchanges in general are not 
independent when performed in parallel, 
so restrictions on cell movements are 
enforced to ensure the consistency of the 
cell rearrangement.) This process repeats 
as the temperature parameter slowly 
lowers, restricting cell movement until the 
solution is acceptable to the designer. 

Circuit simulation. A second area of 
importance to the electronics industry is 
VLSI circuit simulation. Unfortunately, 
our ability to simulate large circuits has not 
kept pace with the increasing number of 
components. Again, this results from the 
computation-intensive nature of simula¬ 
tion. Consequently, often only circuits 
with several hundred transistors are simu¬ 
lated at a time. Just as computer-aided 
design tools have become essential for suc¬ 
cessful implementation of VLSI, designers 
need simulation at the level of analog 
waveforms to verify circuit design. 

Real circuits operate according to the 
characteristics of each component and 
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Figure 6 . Simulation output of VLSI circuit. Waveforms from multiple probe points are displayed for a given input. 


through enforcement of Kirchoff’s law, 
which states that at each node the current 
entering the node is exactly balanced by the 
current leaving the node. In computer 
simulation, this leads to the application of 
an iterative relaxation method at each time 
step, which brings the circuit into 
equilibrium. 

A Gauss-Jacobi relaxation algorithm 
for solving a system of nonlinear differen¬ 
tial equations has been employed to simu¬ 
late VLSI circuits. 10 As implemented on a 
Connection Machine, individual compo¬ 
nents (such as transistors, resistors, or 
capacitors) and nodes are each assigned to 
individual processors. Pointers express the 
connectivity of the circuit. During simula¬ 
tion, the pattern of communication 
directly reflects the topology of the circuit. 


A simulation time step starts with all 
nodes sending their voltages to the termi¬ 
nals of the components to which they con¬ 
nect. In the initial time step, we know only 
the potentials at the power supply and 
ground nodes (others are assumed zero). 
Each element computes its response and 
sends this information back to connecting 
nodes. Each node processor checks to see 
if all currents balance. If so, the time step 
is complete; otherwise, each node proces¬ 
sor updates its expected potential accord¬ 
ing to the relaxation rule, and the cycle 
repeats. In practice, each time step typi¬ 
cally requires three to four iterations and 
accounts for one-tenth of a nanosecond 
simulated time. Figure 6 shows a typical 
simulation. 

Because all operations take place in par¬ 


allel, simulations of circuits with more 
than 10,000 devices can run in a few 
minutes on a 64K-processor Connection 
Machine. Simulations of circuits having 
more than 100,000 transistors have run in 
less than three hours. 

Computer vision. Problems in com¬ 
puter vision pose a major challenge for 
today’s systems not only because the prob¬ 
lem is large (256K pixels in a typical video 
image), but also because we need a variety 
of data structures to meet the differing 
representational requirements of vision. 
We can easily see how to apply massively- 
parallel systems to pixel-level image pro¬ 
cessing, but it is often less clear how par¬ 
allelism applies to higher-level concerns, as 
in the recognition of objects in a scene. 
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Figure 7. Using a stereo pair of left and right terrain images, the system corrects for 
any geometric distortions, detects edge points, computes elevations, and generates 
a contour map for the given terrain. 



Therefore, we show here two examples in 
computer vision: production of a depth 
map from stereo images, and two- 
dimensional-object recognition. 

Depth map from binocular stereo. 
Binocular stereo is a method for determin¬ 
ing three-dimensional distances based on 
comparisons between two different views 
of the same scene. It is used by biological 
and machine vision systems alike. Drum- 
heller and Poggio" have implemented a 
program that solves this problem in near- 
real time and illustrates aspects of per¬ 
forming image analysis on the Connection 
Machine. 

Given a stereo image pair, the program 
produces a depth map expressed in the 
form of a topographic display. First, two 
images (left and right) are digitized and 
loaded into the Connection Machine, with 
pixel pairs from right and left images 
assigned to individual processors. Next, a 
difference-of-Gaussians filter is applied to 
each image to detect edge points, which 
form the primitive tokens to be matched 
in the two images. All pixels perform this 
difference-of-Gaussians convolution in 
parallel. 

To determine the disparity of features 
between left and right images, the Connec¬ 
tion Machine system performs a local 
cross-correlation between the two images. 
It slides the right image over the left using 
NEWS communications. At a given rela¬ 
tive shift, the two edge-point patterns are 
ANDed in parallel, producing a new image 
that has the Boolean value t only at points 
where the left and right images both con¬ 
tain an edge. 

Then each processor counts the number 
of t ’s in a small neighborhood, effectively 
computing the degree of local correlation 
at each point. This occurs at several rela¬ 
tive shifts, with each processor keeping a 
record of the correlation score for each 
shift. 

Finally, each processor selects the shift 
(disparity) at which the maximum corre¬ 
lation took place. 

Since the above process determines dis¬ 
parity (and distance) only at edge pixels, 
we must “fill in” the non-edge pixels by 
interpolation using a two-dimensional 
heat-diffusion model. The resulting depth 
map is displayed either as a gray-scale 
image with density as a function of height 
from the surface, or in standard topology 
map format. The entire process, from 
loading in a pair of 256 x 256-pixel stereo 
images to production of a contour map, 
completes in less than two seconds on a 


36 


COMPUTER 








































Figure 9. Object recognition example showing original image (a), feature extraction (b), hypothesis generation (c), and recogni¬ 
tion and labeling of objects (d). 


64K-processor Connection Machine (see 
Figure 7). 

Object recognition. Recognition of 
objects in natural scenes remains an 
unsolved problem in computer science 
despite attracting research interest for 
many years. It is important in many appli¬ 
cations, including robotics, automated 
inspection, and aerial photo¬ 
interpretation. 

In contrast to many of the systems 
designed to date, the object-recognition 
system described in this section was 
designed to work with object databases 
containing hundreds of models and to 
search each scene in parallel for instances 
of each model object. 12 While this system 
is limited to recognition of two¬ 


dimensional objects having rigid shapes, 
it is being extended to the three- 
dimensional object domain. 

The general framework for the 
approach taken here is massive parallel 
hypothesis generation and test. Whereas 
object-recognition algorithms tradition¬ 
ally use some form of constraint-based tree 
search, here searching is effectively 
replaced by hypothesis generation and 
parameter space clustering. In this scheme, 
image features in the scene serve as events, 
while features of each model serve as 
expectations waiting to be satisfied. 
Hypotheses arise whenever an event satis¬ 
fies an expectation. 

On the Connection Machine, objects 
known to the system are represented sim¬ 
ply as a collection offeatures—generally 


straight line-segments and their intersec¬ 
tions at corners. Each feature is assigned 
to its own processor. A single object is 
therefore distributed over a number of 
processors, enabling each feature to 
actively participate in the solution. 

Features useful for hypothesis genera¬ 
tion are those that constrain the position 
and orientation of a matching model 
object. A single point, line, or patch of 
color is by itself not sufficient. In a two- 
dimensional world, however, the intersec¬ 
tion of two lines that matches an expected 
model corner can be used to generate a 
hypothesis that an instance of the model 
object exists—albeit translated and rotated 
such that the corresponding features come 
into alignment. 

Figure 8 illustrates this parallel hypoth- 
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esis generation and verification method. 
An unknown scene is first digitized and 
loaded into the Connection Machine mem¬ 
ory as an array of pixels, one per proces¬ 
sor. Edge points are marked and straight 
line segments are fitted to edge points 
using a least-squares estimate. Intersecting 
lines are grouped into corner features and 
matched in parallel with corresponding 
corner features in the model database. 

Whenever a match between an image 
and model feature occurs, a hypothetical 
instance of the corresponding model 
object is created and projected into the 
image plane. A hypothesis-clustering 
scheme, related to the Hough transform, 
is next applied to order hypotheses accord¬ 
ing to the support offered by mutually sup¬ 
porting hypotheses. Although this still 
leaves many possible interpretations for 
each image feature, the Connection 
Machine can quickly accept or reject thou¬ 
sands of hypotheses in parallel using a 
template-like verification step. 

Verification results from having each 
instance check the image for evidence sup¬ 
porting each of its features in parallel. 
Hypotheses having strong support for 
their expected features are accepted over 
those with little support. Expected features 
of an object that are occluded or obscured 
in the scene do not rule out the hypothe¬ 
sis, they only weaken the confidence the 
system has in the object’s existence. Com¬ 
petitive matching between instances for 
each image feature finally resolves any 
conflicts that arise in the overall scene 
interpretation. Results appear in Figure 9. 

The time required from initial image 
acquisition to display of recognized 
objects is approximately six seconds on a 
64K-processor Connection Machine. 
Experiments have shown this time to be 
constant over a range of object database 
sizes from 10 to 100. We expect optimiza¬ 
tion of this task to reduce the time to less 
than one second. 


T he Connection Machine 
represents an exciting approach to 
dealing with the large and com¬ 
plex problems that a growing number of 
people wish to solve with computer sys¬ 
tems. The size of problems has grown at a 
rate faster than improvements in technol¬ 
ogy, forcing us to find innovative ways of 
using current technology to achieve quan¬ 
tum leaps in performance. 

We have described the architecture and 
evolution of the Connection Machine, 
which directly implements a data-parallel 


model in hardware and software. From the 
applications described here and elsewhere, 
it seems clear to us that data-level parallel¬ 
ism has broad applicability. We expect 
that its applicability will continue to grow 
as people continue to require solutions to 
larger and more complex problems.□ 
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simplifies future analysis and revision. 
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seamless, allowing you to go back and forth 
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The Visible Analyst Workbench operates 
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Automatic Programming: 
Myths and Prospects 


Charles Rich and Richard C. Waters 
Massachusetts Institute of Technology 


A utomatic programming has been 
a goal of computer science and 
artificial intelligence since the 
first programmer came face to face with 
the difficulties of programming. As befits 
such a long-term goal, it has been a mov¬ 
ing target—constantly shifting to reflect 
increasing expectations. 

Much of what was originally conceived 
of as automatic programming was 
achieved long ago (see the sidebar on its 
status in 1958). On the other hand, current 
expectations regarding its potential are 
often based on an idealized view of reality 
and are probably unachievable. Neverthe¬ 
less, a number of important developments 
are appearing in research efforts and in 
commercially available systems. 

Automatic programming 
myths and realities 

Th e “cocktail par ty’’ description of the 

something like this: < 

There will be no more program¬ 
ming. The end user, who only 
needs to know about the applica¬ 
tion domain, will write a brief 
requirement for what is wanted. 
The automatic programming sys¬ 
tem, which only needs to know 
about programming, will produce 
an efficient program satisfying the 



The “cocktail party” 
description of 
automatic 
programming is 
unachievable because 
it is based on faulty 
assumptions; 
nevertheless, we will 
see continued 
evolutionary progress. 


I 

requirement. Automatic pro¬ 
gramming systems will have three 
key features: They will be end-user 
oriented, communicating directly 
with end users; they will be general 
purpose, working as well in one 
domain as in another; and they 
will be fully automatic, requiring 
no human assistance. 


Although this description is attractive, it 
is based on a number of faulty 
assumptions. 

Myth: End-user-oriented automatic 
programming systems do not need domain 
knowledge. It is no more possible for end 
users to communicate effectively with an 
automatic programming system that 
knows nothing about the application 
domain than it is for them to communicate 
effectively with a human programmer who 
knows nothing about the application 
domain. Rather, the path from an end 
user’s needs to a program involves a 
gradual progression from a description 
that can be understood only in the context 
of the domain to a description that can be 
understood without relying on auxiliary 
knowledge (see the sidebar on agents in the 
programming process). There is no point 
at which someone who knows nothing 
about programming communicates 
directly with someone who knows nothing 
about the application domain. 

Reality: End-user-oriented automatic 
programming systems must be domain 
experts. In particular, it is not possible to 
describe something briefly unless the 
hearer knows at least as much about the 
domain as the speaker does and can there¬ 
fore understand the words and fill in what 
is left out. (For a detailed discussion of the 
necessity of domain knowledge in auto¬ 
matic programming, see Barstow. 1 ) 


"40 


8-9162/88/0800-0040S01.00 if 1988 IEEE 


COMPUTER 














Myth: End-user-oriented, general- 
purpose, fully automatic programming is 
possible. A corollary of the need for 
domain knowledge is that such an auto¬ 
matic programming system would have to 
be expert in every application domain. 
Unfortunately, artificial intelligence is 
nowhere near supporting this superhuman 
level of performance. 

Reality: Given the pragmatic impossi¬ 
bility of simultaneously supporting all 
three features, it is not surprising that all 
current approaches to automatic program¬ 
ming focus on two of the features at the 
expense of the third. This has given rise to 
the following three approaches to auto¬ 
matic programming, typified by the fea¬ 
ture given up: 

(1) Bottom up. This approach sacrifices 
end-user orientation. It starts at the 
programmer’s level and tries to push 
the threshold of automation 
upward. In the past, the threshold 
was raised from machine-level to 
high-level languages. The current 
goal is to raise the threshold further 
to so-called very high level lan¬ 
guages. 

(2) Narrow domain. This approach 
sacrifices being general purpose. 
Focusing on a narrow enough 
domain makes it feasible right now 
to construct a fully automatic pro¬ 
gram generator that communicates 
directly with end users. This 
approach is advancing to cover 
wider domains. 

(3) Assistant. This approach sacrifices 
full automation. Instead, it seeks to 
assist in various aspects of program¬ 
ming. With current technology, this 
approach is represented by pro¬ 
gramming environments consisting 
of collections of tools such as intel¬ 
ligent editors, on-line documenta¬ 
tion aids, and program analyzers. 
The goal here is to improve the inte¬ 
gration between tools and the level 
of assistance provided by individual 
tools. 

Myth: Requirements can be complete. 

Since the cocktail party description of 
automatic programming assumes that the 
only point of contact between the end user 
and the system is a requirement, this 
requirement must be complete. In the 
interest of producing an efficient program, 
the automatic programming system is 
expected to take full advantage of every 
degree of freedom allowed by the require¬ 
ment. The completeness of the require¬ 


ment guarantees that anything the 
automatic programming system produces 
will be acceptable to the end user. 

This point of view is commonly justified 


by likening requirements to legal con¬ 
tracts. However, any lawyer will tell you 
that contracts do not work that way. Con¬ 
tracts work only when both parties make 


Automatic programming in 1958 

The chart below lists the “automatic programming systems” known to ACM's 
editors as of April 1958. It specifies the computer each system runs on and indi¬ 
cates whether comprehensive documentation for the system was available in a 
library maintained by the ACM. Most of the systems listed are what we now call 
assemblers; a few (notably Fortran for the IBM 704) are compilers. 

The principal lesson provided by this chart is that the term “automatic pro¬ 
gramming” has always been relative rather than absolute. In 1988, no one would 
call any of these systems automatic programming. In 1958, however, the term 
was quite appropriate. 

Compared with programming in machine code, assemblers represented a 
spectacular level of automation. Moreover, Fortran was arguably a greater step 
forward than anything that has happened since. In particular, it dramatically 
increased the number of scientific end users who could operate computers with¬ 
out having to hire a programmer. 

The chart has been reprinted with permission from the ACM (Communications 
of the ACM, Vol. 1, No. 4, April 1958, page 8). 


AUTOMATIC PROGRAMMING SYSTEMS 
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Agents in the programming process 




a-tet qe com pany needs a 
system. This figure 


new accou 

showsThe principal agents that typi¬ 
cally would be involved. The bars on 
the right indicate that near the top of 
the figure, accounting knowledge 
plays the crucial role, while program¬ 
ming knowledge dominates toward 
the bottom. 

The manager at the top of the fig¬ 
ure quite likely has only a rudimen¬ 
tary knowledge of accounting. The 
manager’s job is to identify a need 
and initiate the programming pro¬ 
cess by creating a brief, vague 
requirement. Use of the term “vague” 
here highlights the fact that the only 
way this initial requirement can suc¬ 
ceed in being brief is for it also to be 
incomplete, ambiguous, and/or 
inconsistent. 

The next agent in the process is an 
accounting expert, whose job is to 
take the manager’s vague require¬ 
ment and create a detailed require¬ 
ment. A key feature of this 
requirement is that it is couched in 
the technical vocabulary of account¬ 
ing and is intended for evaluation by 
other accounting experts. The 
accounting expert’s knowledge of 
programming does not have to 
extend much beyond basic notions 
of feasibility. 


The third agent in the process is 
some sort of systems analyst, whose 
job is to define the basic architecture 
of the program and translate the 
requirement into a detailed specifica¬ 
tion. In contrast to the requirement, 
the specification is couched in the 
technical vocabulary of programming 
rather than accounting. To perform 
this transformation, the systems ana¬ 
lyst must have a considerable under¬ 
standing of accounting in addition to 
an extensive knowledge of pro¬ 
gramming. 

The final agent is a programmer, 


Manager 


Accounting 

expert 


Systems 

analyst 


© 


who must produce code in a high- 
level language on the basis of the 
detailed specification. The program¬ 
mer does not have to know very 
much about accounting. However, it 
is very unlikely that the accounting 
system will actually work if the pro¬ 
grammer knows nothing about 
accounting. 

Although not shown in the figure, 
agents for validation, testing, 
documentation, and modification are 
required as well. To do their jobs, 
these agents also need significant 
domain knowledge. 

Domain 
knowledge 


Detailed 

requirement 


© 


Specification 


Programmer 

T 


Programming 

knowledge 


a good-faith effort to work toward a com¬ 
mon end. If good faith breaks down, the 
parties can always cheat without violating 
the “letter” of the contract. 

The problem with requirements (and 
contracts) is that they cannot be complete. 
No matter how trivial the situation, there 
is no practical limit to what must be said 
when trying to pin down a potential 
adversary. 

Consider, for example, specifying a 
controller for an automated teller 
machine. When describing the withdrawal 
operation, it is easy enough to say that 
after inserting the bank card the customer 
should enter a password, select an 
account, and then select an amount of cash 
which the machine then dispenses. How¬ 
ever, this is nowhere near complete. 

To start with, a lot of details are miss¬ 
ing regarding the user interface: What 
kinds of directions are displayed to the cus¬ 
tomer? How is the customer to select 


among various accounts? What kind of 
acknowledgment is produced? To be com¬ 
plete, these details must include the layout 
of every screen and printout, or at least a 
set of criteria for judging the acceptabil¬ 
ity of these layouts. 

Even after the interface details are all 
specified, the requirement is still far from 
complete. For example, consider just the 
operation of checking the customer’s pass¬ 
word. What are passwords to be compared 
against? If this involves a central reposi¬ 
tory of password information, how is this 
to be protected against potential fraud 
within the bank? What kind of response 
time is required? Is anything to be done to 
prevent possible tampering with bank 
cards? 

Looking deeper, a truly complete 
requirement would have to list every pos¬ 
sible error that could occur—in the cus¬ 
tomer’s input, the teller machine, the 
central bank computer, the communica¬ 


tion lines—and state exactly how each 
error should be handled. 

Beyond what is computed, the user 
undoubtedly wants a reasonably efficient 
program. This could be specified as max¬ 
imum limits on space and time. However, 
what is really desired is for the imple- 
menter to make a good-faith effort to 
make the program as efficient as possible. 
Further, the code produced should be easy 
to read and modify, and well documented. 

Finally, the end user also cares about the 
cost of implementing the program and 
how long implementation will take. This 
implies a need for trade-offs, particularly 
when it comes to the last few issues men¬ 
tioned above. Thus, it is very difficult— 
if not impossible—to make complete state¬ 
ments about these issues. 

Reality: At best, requirements are only 
approximations. Instead of serving as a 
.defensive measure between adversaries, 
requirements should serve as a tool for 
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communication between colleagues. 
Assuming that the implementer will make 
a good-faith effort to create a reasonable 
program, many of the points above can go 
unsaid. 

Just like human programmers, an auto¬ 
matic programming system must make a 
good-faith effort to satisfy the spirit of the 
requirements. The system must be oriented 
toward making reasonable assumptions 
about unspecified properties, rather than 
trying to minimally satisfy specified 
properties. This observation reinforces the 
need for domain knowledge as part of an 
automatic programming system. 

Myth: Programming is a serial process. 

In many ways, the worst aspect of the 
cocktail party description of automatic 
programming is that it perpetuates the 
myth that creating a program is a two-step 
processf First, an end user creates a 
requirement; second, the automatic pro¬ 
gramming system makes a program. This 
view is just as impractical in the context of 
an automatic programming system as it is 
in human-based programming. 

First of all, given the approximate 
nature of requirements, a considerable 
amount of back-and-forth communica¬ 
tion is required to convey the end user’s 
full intent. Second, users typically start the 
programming process with only a vague 
idea of what they want, and they need sig¬ 
nificant feedback to flesh out their ideas 
and determine the exact requirement. 
Also, what end users want today is never 
the same as what they want tomorrow. 
Third, users do not want programmers to 
follow requirements blindly. If problems 
arise, they want advice. For example, the 
programmer should tell the user if a slight 
relaxation in the requirement would allow 
a much more efficient algorithm to be 
used. 

Reality: Programming is an iterative 
process featuring continual dialogue 
between end user and programmer. The 
desired requirement evolves on the basis of 
prototypes and initial versions of the 
system. 

The inherently iterative nature of pro¬ 
gramming has two important implications 
for automatic programming. First, just as 
in nonautomatic programming, the focus 
of activity will be on changing require¬ 
ments as much as on implementing them. 
Thus, there will be no reduction in the need 
for regression testing and other techniques 
for managing evolution. 

Second, to carry on a dialogue with the 
user, automatic programming systems will 


Automatic 

programming systems 
of the future will be 
more like vacuum 
cleaners than like 
self-cleaning ovens. 


have to explain what they have done and 
why. In particular, they will need to 
explain the assumptions they have intro¬ 
duced into a requirement, so that users can 
debug those assumptions. 

Myth: There will be no more program¬ 
ming. There will certainly be many differ¬ 
ences between the input to future 
automatic programming systems and what 
is currently called a program. However, 
programming is best typified not by what 
programs are like but by what program¬ 
ming tasks are like. Undoubtedly these 
new inputs will still have to be carefully 
crafted, debugged, and maintained 
according to changing needs. Whether or 
not one chooses to call these inputs pro¬ 
grams, the tasks associated with them will 
be strongly reminiscent of programming. 

Reality: End users will become 
programmers. As an example of this 
phenomenon, consider spreadsheet pro¬ 
grams. When spreadsheets first appeared, 
they were heralded as a way to let users get 
their work done without having to deal 
with programmers or learn programming. 
Spreadsheets have succeeded admirably in 
letting users get results by themselves. 
However, maintaining a spreadsheet over 
time differs very little from maintaining a 
program. The only real difference is that 
a spreadsheet is a concise domain-specific 
interface that makes it remarkably easy to 
write certain kinds of programs and 
startlingly hard to write other kinds of 
programs. 

Myth: There will be no more program¬ 
ming in the large. Even if we accept that 
programming will be around forever, we 
might well hope that by continuing the 
trend of writing programs more com¬ 
pactly, automatic programming will con¬ 


vert all programming into programming in 
the small. 

Unfortunately, this dream overlooks 
software’s extreme elasticity of demand. 
Most of the productivity improvements 
introduced by automatic programming 
will almost certainly be used to attack 
applications that are enormous rather than 
merely huge. 

Reality: We are not likely to ever settle 
for only those application systems that can 
be created by a few people. As a result, 
there will be no lessening of the need for 
version control, management aids, and all 
the other accoutrements of cooperative 
work and programming in the large. 

A down-to-earth perspective. The auto¬ 
matic programming systems of the future 
will be more like vacuum cleaners than like 
self-cleaning ovens. With a self-cleaning 
oven, all you have to do is decide that you 
want the oven cleaned and push a button. 
With vacuum cleaners, your productivity 
is greatly enhanced, but you still have a lot 
of work to do. 

Our discussion of the fundamental tech¬ 
nical issues in automatic programming will 
be divided according to three questions 
that must be addressed in the design of any 
automatic programming system: What 
does the user see? How does the system 
work? What does the system know? 

We will also review the most recent 
trends in currently available automated 
programming tools. Under the rubric of 
computer-aided software engineering, or 
CASE, these tools are following the 
bottom-up, narrow-domain, and assistant 
approaches to automatic programming. 

Finally, we offer ideas on the kinds of 
tools that will soon be available. CASE 
tools in particular are poised to emerge 
from a somewhat rocky adolescence into 
maturity. In this regard, we observe that 
the path toward automatic programming 
is impeded as much by the need for 
managerial change as by the need for tech¬ 
nical advances. 

What does the user see? 

From the user’s perspective, the most 
prominent aspect of an automatic pro¬ 
gramming system is the language used to 
communicate with it. The range of possi¬ 
bilities is illustrated in the accompanying 
sidebar on input languages and is further 
discussed below. 

Natural language. Because they are 
familiar, natural languages such as English 
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Potential inputs to an automatic programming system 

The figures in this sidebar illustrate the wide variety of inputs an automatic programming system might support. Each 
example is a specification for a program that determines the value of an octal number represented in a string. A Pascal 
implementation is included that illustrates what the output of an automatic programming system might look like. Note that 
no single example can illustrate all of the important issues in selecting an input medium. 


The function EvalOctal is a recog¬ 
nizer that determines whether a 
given string contains an octal num¬ 
ber optionally surrounded by 
blanks. If this is the case, the deci¬ 
mal value of the number is returned. 
Otherwise -1 is returned. 


A natural language (English). 


A special-purpose language 
(state transition diagrams). 


'O' < a < T 
V := 8*V+Digit(a) 



"132 " - 90 
" 42 " - 34 
" 56" - 46 
"-17 " - -1 
"2.6 " - -1 
" 380" - -1 


Examples (input/output pairs). 


A logical formalism 
(predicate calculus). 


input: S 

precondition: String(S) 
output: V 

postcondition: Integer(K) A (Valid(S)-♦ Value(S, V)) A (-'Valid(S)-*• V=-l) 


where: 

Valid(S) ^ (Vi 1 < / < |S| -*■ S(/)€{’ ’,’1’,’2’,’3’,’4’,’5’,’6’,’7’}) A 
(3/ 1</<|S| -* S(i)*’ ’) A 

(-i 3ijk l<i<j<k<\S\ A S(/)*’ ’ A S(J) = ’ ’ A SHk)*' ’) 
Value(S, V) = Vi/ (1 «=/</< |S| A S(/)=A’ ’ A SO)*’ ’ A (j=\S\ V S(y+1) = ’ ’)) 
-(Digit(S(/)) = Div(Rem(K, 8' '-'), S J -‘~ 2 ) 

A ((/= 1 V S(i- 1) = ’ ’) - K<8'-'» 


procedure EvalOctal(S); 

if (forall C in S | C in {’ and 

(exists C in S | C / = ’ ’) and 
(not exists Ci in S(i), Cj in S(j), Ck in S(k) 

| i<j and j<k and Ci/ = ’ ’andCj = ’ ’andCk/ = ’ ’) 
then Digits: = [abs C - abs ’O’: C in S | C/ = ’ ’]; 

return +/[D*8**(#Digits-i): D in Digits(i)]; 
else return -1; 
end if; 

end procedure EvalOctal; 


A very high level language (SETL). 


function EvalOctal (var S array [M..N: Integer] ofXhar): 
Integer; 

{End of input string flagged with chr(0).} 
var J, V: Integer; 
begin 
J : = M; 

V : = -1; 

while S[J] = ’ ’ do J : = J + l; 
if S[J] < > chr(0) then begin 
V : = 0; 

while (’O’ < = S[J]) and (S[J] < = ’7’) do begin 
V := 8*V + ord(S[J])-ord(’0’); 

J := J+l 
end; 

while S[J] = ’ ’ do J := J+l; 
if S[J] < >chr(0) then V := -1 
end; 

EvalOctal : = V 
end 


A high-level language (Pascal). 
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are an attractive choice for communica¬ 
tion between end users and an automatic 
programming system. Three features that 
make natural language attractive are 
vocabulary, informality, and syntax. As 
discussed later, the existing vocabulary of 
thousands of predefined words contrib¬ 
utes most to making natural language an 
efficient communication medium. 

Informality (for example, the possibil¬ 
ity of a statement’s being ambiguous, 
incomplete, contradictory, and/or inac¬ 
curate) is also very important. In fact, it is 
essential to a powerful strategy for dealing 
with complexity: Start with an almost- 
right description and incrementally 
modify it until it is acceptable. An interest¬ 
ing research direction is the design of arti¬ 
ficial languages that intentionally allow 
informality. 

Syntax is the least important feature of 
natural language. Natural syntax is con¬ 
venient because it is familiar. However, it 
is of relatively little value unless the other 
features are supported as well. 

Unfortunately, enabling machines to 
converse in natural language is way 
beyond the current capabilities of artificial 
intelligence. As a result, natural language 
input—although an active area of inquiry 
in its own right—is not a major topic in 
current automatic programming research. 

Special-purpose languages. Even when 
people communicate among themselves, 
natural language is not always the lan¬ 
guage of choice. For example, many appli¬ 
cation areas have specialized symbolic or 
graphical languages associated with them 
(mathematical formulas and circuit dia¬ 
grams, for instance) that experts routinely 
use in preference to natural language. 

Many kinds of special-purpose lan¬ 
guages can be supported in straightfor¬ 
ward ways, as long as their focus is 
sufficiently narrow. A particularly suc¬ 
cessful example is the so-called “what you 
see is what you get” interfaces. Screen 
painters allow end users to specify the lay¬ 
out (and some of the semantics) of a data- 
entry-and-retrieval program by simply 
making a picture of how the screen should 
look. Then a code generator automatically 
writes the code to drive the terminal and 
access the database. 

Unfortunately, special-purpose lan¬ 
guages have a fundamental problem: They 
are essentially useless outside their 
domains of applicability. This brings up a 
key unsolved problem—namely, how to 
combine several special-purpose languages 
or a special-purpose language with a 


general-purpose one. 

Almost every current system that sup¬ 
ports a special-purpose language follows 
the narrow-domain approach to auto¬ 
matic programming, restricting itself to 
situations where the special-purpose lan¬ 
guage is appropriate. Even when multiple 
special-purpose input languages are sup¬ 
ported, 2 the user can only combine the 
languages in simple ways. Much more 
work is necessary before special-purpose 
languages can reach their full potential as 
part of the interface to general-purpose 
systems. 

Examples. An attractive idea, pursued 
with some vigor in the early days of auto¬ 
matic programming, is to specify a pro¬ 
gram via examples of its behavior. The 
appeal of this approach is that non¬ 
programmers are familiar with examples 
as a communication technique, just as they 
are with natural and special-purpose lan¬ 
guages. Furthermore, collections of exam¬ 
ples are easy to understand and modify. 

Unfortunately, except for toy problems, 
no one has been able to make an example- 
based automatic programming system 
work, and there is reason to believe this 
failure is fundamental. It is trivial, but use¬ 
less, to construct a program that duplicates 
a particular set of examples and does noth¬ 
ing else. What is desired is a program that 
operates on whole classes of input data in 
a manner “analogous to” the examples. 
However, experience has shown that no 
matter how many examples are provided, 
there is no way to ensure that the generali¬ 
zation derived will be correct—without 
placing severe constraints on the domain 
of possible generalizations. 

Logical formalisms. Logic is the most 
powerful (and general) formal description 
language known. As a result, it is reasona¬ 
ble to suppose that it might make a good 
communication medium between a user 
and an automatic programming system. 

Unfortunately, there are two fun¬ 
damental barriers to the use of logical for¬ 
malisms. First, most interesting tasks in 
general logical systems (for example, 
detecting contradictions) are computa¬ 
tionally intractable (see the discussion of 
deductive methods in the next section). 
Second, complex logical formulas are 
notoriously difficult for most people to 
write and understand. 

Research on logic as a communication 
medium between man and machine is 
being carried out primarily under the 
topics of formal specification languages 


and logic-programming languages. A key 
issue in both of these areas is the introduc¬ 
tion of extensions and restrictions that ren¬ 
der logic more tractable to man and 
machine. For example, Prolog 3 guaran¬ 
tees executability of logical descriptions by 
placing strong restrictions on the form of 
expressions. 

Very high level languages. While speci¬ 
fication languages and logic-programming 
languages essentially extend downward 
from logic, very high level languages build 
upward from current high-level languages. 
Typically, very high level languages add 
powerful abstract data types, such as sets 
and mappings (to allow programmers to 
ignore the details of data structure imple¬ 
mentation), and a few features of logical 
notation, such as quantification over sets 
(to allow programmers to ignore certain 
kinds of algorithmic detail). 

The archetype of very high level lan¬ 
guages is SETL. 4 More recent very high 
level languages, such as Refine 5 and Gist, 6 
have added other features—for example, 
constraints and nondeterminism. 

Other communication issues. Beyond 
the topics discussed above, the following 
three general issues apply to any commu¬ 
nication medium. 

First, a medium should be wide- 
sped rum . The user should be able to 
specify everything from very abstract 
properties to low-level implementation 
advice. This is necessary (at least for the 
foreseeable future) because automatic pro¬ 
gramming systems cannot operate without 
getting a certain amount of advice at all 
levels. It is desirable for wide-spectrum 
communication to be supported in a sin¬ 
gle coherent formalism. However, in addi¬ 
tion to a general-purpose wide-spectrum 
language, the ideal automatic program¬ 
ming system would support a number of 
special-purpose languages. 

Second, because of programming’s 
inherently iterative nature, a medium must 
be able to support a dialogue between the 
user and the automatic programming sys¬ 
tem. Therefore, serious attention must be 
paid to the language the system is going to 
use when speaking to the user. In addition, 
the input language must be capable of 
expressing “metalevel” information, that 
is, information about changes to the state 
of knowledge. One can imagine how nat¬ 
ural language would serve well as a dia¬ 
logue medium; however, restricted 
notations, such as very high level lan- 
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guages, are clearly not sufficient by them¬ 
selves. 

Third, a medium should come with a 
large vocabulary of predefined terms so 
that the system can converse with the user 
at a suitably high level. Given a choice, 
most users would prefer to use an awk¬ 
ward medium in which almost everything 
they want is already defined, rather than 
an otherwise convenient medium in which 
everything needs to be defined from first 
principles. 

How does the system 
work? 

Automatic programming systems map 
a configuration of domain-specific terms 
(a requirement stated in terms of one of the 
input mediums above) into a configuration 
of implementation-specific terms (a pro¬ 
gram). Four mechanisms currently being 
pursued as a basis for such systems are 
procedural methods, deductive methods, 
transformational methods, and inspection 
methods. 

Procedural methods. To date, the most 
successful approach has been to simply 
write a special-purpose program that gets 
the right results. For example, most cur¬ 
rent compilers and program generators are 
essentially procedural in nature, although 
a few use transformations to some extent. 

The big advantage of procedural 
methods is that they let you get off the 
ground fast. It is very seldom difficult to 
support the first few desired features. Fur¬ 
thermore, you can always (try to) modify 
the code to support any additional feature. 

Unfortunately, as more and more fea¬ 
tures are added to a procedural system, 
you reach a point of rapidly diminishing 
returns, because the system becomes 
progressively more difficult to modify. As 
a result, it is unlikely that the procedural 
approach can support the broad-coverage 
end-user-oriented automatic program¬ 
ming systems of the future. 

Deductive methods. The problem of 
synthesizing a program satisfying a given 
specification is formally equivalent to 
finding a constructive proof of the speci¬ 
fication’s satisfiability. This fundamental 
idea underlies the deductive approach to 
automatic programming. 7 In principle, 
any method of automated deduction— 
resolution, natural deduction, reasoning 
about anonymous individuals—can be 
used to support automatic programming. 


Like engineers in 
other disciplines, 
programmers think 
mostly in terms 
of cliches. 


Unfortunately, in practice none of these 
methods is yet able to prove the kinds of 
complex theorems required to synthesize 
programs of realistic size. 

Deduction is basically a problem of 
searching for an inference path from some 
initial set of facts to a goal fact. The search 
is exponential in nature because at every 
step there are many ways for inference 
rules to be applied to facts. Current deduc¬ 
tive systems cannot discover complex 
proofs because they are unable to effec¬ 
tively control the search process. 

To deal with this control problem, 
deductive systems typically must adopt the 
assistant approach—that is, they seek 
advice from the user. Unfortunately, users 
who want to avoid programming probably 
want to avoid theorem proving as well. 

An even more fundamental problem 
with the deductive approach is that it is at 
odds with the need for an automatic pro¬ 
gramming system to make a good-faith 
effort to satisfy the “spirit” of a require¬ 
ment. For example, the theorem-proving 
process contains no bias toward finding 
the proof corresponding to the most effi¬ 
cient program, or even a reasonably effi¬ 
cient program. 

Despite these limitations, deductive 
methods have several advantages. In par¬ 
ticular, they are very general and quite 
effective, as long as they are limited to 
proving simple theorems. As a result, 
deductive methods are certain to play an 
important role in the automatic program¬ 
ming systems of the future. The challenge 
is to combine automated deduction with 
other methods so that its inherent limita¬ 
tions can be avoided. 

Transformational methods. Transfor¬ 
mational implementation systems 8 (for 
example, TI 6 and PDS 9 ) dominate current 
research in automatic programming. In 
this approach, the input to the automatic 


programming system is a program written 
in a very high level language. A sequence 
of transformations is applied to convert 
this input into a low-level implementation. 

A transformation has three parts: a pat¬ 
tern, a set of logical applicability condi¬ 
tions, and an action procedure. When an 
instance of the pattern is found, the logi¬ 
cal applicability conditions are checked to 
see whether the transformation should be 
applied. If the applicability conditions are 
satisfied, the action is evaluated to com¬ 
pute a new section of code, which is used 
to replace the code matched by the pattern. 
Typically, transformations are correctness 
preserving , meaning that the matched code 
and its replacement represent logically 
equivalent computations. 

Two basic kinds of transformations 
exist. Some transformations replace 
specification-like constructs (for example, 
quantification over a set) with conven¬ 
tional constructs (for example, iteration 
over a list). These transformations encode 
knowledge of how to implement 
algorithms and data structures. Other 
transformations perform rearrangements 
and optimizations (for example, moving 
an unchanging computation out of a 
loop), which do not change the level of 
abstraction. In practice, these two kinds of 
transformations are interleaved in long 
sequences, passing through multiple levels 
of abstraction. 

The central feature of transformational 
methods is the transformational rewrite 
cycle. The state of the transformation pro¬ 
cess is represented as a program in a wide- 
spectrum representation capable of 
expressing both the user’s input and the 
desired result. On each cycle, a transfor¬ 
mational system selects a transformation 
and applies it to some place in the pro¬ 
gram. The cycle continues, accumulating 
the results of longer and longer chains of 
transformations, until some condition is 
satisfied (for example, until there are no 
more very high level constructs). 

In many ways, sequences of transfor¬ 
mation steps are not that different from 
sequences of proof steps. Therefore, it is 
not surprising that transformational 
implementation systems suffer from essen¬ 
tially the same control problem as auto¬ 
matic theorem provers. As a consequence, 
transformational systems must either seek 
advice from the user or place strong res¬ 
trictions on the kinds of transformations 
that can be used. Unfortunately, advice¬ 
taking transformational systems are not 
much more satisfactory than advice-taking 
deductive systems and have not yet made 
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it out of the laboratory. However, 
restricted transformational modules can 
be found as components of various com¬ 
pilers and other systems. 

An interesting aspect of transformation 
sequences is that they usually contain a 
small percentage of key steps (typically 
making decisions about how to implement 
abstractions) interleaved with many small, 
less intuitive steps that set things up and 
move things around. Current research on 
transformational methods is directed 
toward automating the many small steps 
while seeking user advice on the key steps. 

A major strength of transformational 
methods is that they provide a very clear 
representation for certain kinds of pro¬ 
gramming knowledge. For this reason, 
transformational methods in some form 
are certain to be part of all future auto¬ 
matic programming systems. 

Inspection methods. Human program¬ 
mers seldom think only in terms of primi¬ 
tive elements such as assignments and 
tests. Rather, like engineers in other dis¬ 
ciplines, they think mostly in terms of 
cliched combinations of elements cor¬ 
responding to familiar concepts. Succes¬ 
sive approximation, interrupt-driven 
architecture, and information system are 
examples of cliches spanning the range 
from low-level implementation ideas to 
high-level specification concepts. 

Given a knowledge of cliches, it is pos¬ 
sible to perform many programming tasks 
by inspection rather than by reasoning 
from first principles. For example, in anal¬ 
ysis by inspection, properties of a program 
are deduced by recognizing occurrences of 
cliches and referring to their known 
properties. In synthesis by inspection, 
implementation decisions are made by 
recognizing cliches in specifications and 
then choosing among various cliched 
implementations. By using global under¬ 
standing, inspection methods reduce the 
search-control problems that arise with 
other methods. 

The central feature of inspection 
methods is the codification and use of 
cliches. A cliche has three parts: a skeleton 
that is present in every occurrence of the 
cliche, roles whose contents vary from one 
occurrence to the next, and constraints on 
what can fill the roles. An essential prop¬ 
erty of cliches is their interrelationships. 
For example, a cliche may specialize or 
extend another cliche. Algorithmic and 
data structure cliches implement specifica¬ 
tion cliches. These relationships are the 
driving force behind analysis and synthe¬ 


sis by inspection. 

As with deductive and transformational 
methods, it has not yet been shown that 
inspection methods can be automated 
without advice from the user. However, 
when used with the assistant approach to 
automatic programming, inspection 
methods have an important advantage: A 
shared vocabulary of cliches is a natural 
medium for communicating explanations 
and advice between the system and the 
user. 

Following the assistant approach, the 
Programmer’s Apprentice project 10 ' 11 has 
demonstrated several aspects of inspection 
methods. For example, given a library of 
cliches, the system can automatically ana¬ 
lyze a program to identify the algorithms 
used. In addition, programs can be con¬ 
structed by combining user-selected 
cliches. Current research is directed 
toward automatic selection of some of the 
cliches to use. 

In human programming, inspection 
methods are the most effective approach, 
whenever applicable. However, since 
inspection methods are ultimately based 
on experience, they apply only to the rou¬ 
tine parts of programming problems. As 
a result, inspection methods must be used 
as part of a hybrid strategy that falls back 
on more general methods such as deduc¬ 
tion and transformation when inspection 
fails. 

What does the system 
know? 

No matter what mechanism is used 
inside an automatic programming system, 
the system must have at least an implicit 
knowledge of domain cliches (so that it can 
interpret the terms used by the user) and of 
programming cliches (so that it can pro¬ 
duce programs without endlessly “rein¬ 
venting the wheel”). Whether knowledge 
of cliches is represented procedurally, log¬ 


ically, transformationally, or in some 
other way, the benefits of automatic pro¬ 
gramming can be traced almost exclusively 
to the productivity and reliability benefits 
of reusing this knowledge. The following 
examples of programming cliches illus¬ 
trate the diversity of knowledge required: 

Matrix add —the algorithm for adding 
together two matrices. This cliche is 
independent of the data representation 
of the matrices and the type of number 
stored in the matrices. 

Stack —the data abstraction and its 
associated operations. Both the repre¬ 
sentation and the operations are 
independent of the type of stack 
element. 

Filter positive —selecting the positive 
elements of a temporal sequence of 
quantities in a loop. For example, in the 
code fragment below, the if statement 
implements a filter positive. 

do . . . 

X:= . . . ; 

if X>0 then ... X ... ; 
end; 

This cliche is independent of the type of 
number in the sequence and how the 
sequence is generated. 

Master file system—a cluster of pro¬ 
grams (reports, updates, audits, etc.) 
that operate on a single master file, 
which is the sole repository for informa¬ 
tion on some topic. This cliche is essen¬ 
tially a set of constraints on the 
programs and how they interact with the 
file. It is independent of the kind of data 
stored in the file and the details of the 
computation performed by the 
programs. 

Deadlock free —the property of a set of 
asynchronously interacting programs 
that guarantees they will not reach a 
state where each program is blocked 
waiting for some other program to act. 
This cliche restricts the ways in which 
the programs can interact. However, it 
is independent of the details of the com¬ 
putations performed by the programs. 

The cliches above differ along many 
dimensions. Matrix add is primarily com¬ 
putational, while stack is data oriented. 
Matrix add can be used in a program as a 
module, while filter positive is fragmen¬ 
tary and must be combined with other 
fragments to be useful. Matrix add, stack, 
and filter positive are all relatively low- 
level, localized cliches. In contrast, mas- 
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Programming-knowledge representations 


This diagram traces the 
inheritance of ideas among the 
major approaches that have been 
used to represent programming 
knowledge. The two oldest 
approaches are subroutines and the 
encoding of knowledge in proce¬ 
dures that “write the right code.” 
Subroutines are very limited in 
expressive power but are easy to 
combine. In contrast, procedural 
encoding has unlimited expressive 
power but makes it very hard to com¬ 
bine cliches. 

Program schemas extend the 
expressive power of subroutines, 
while macros are essentially a 
restricted and more tractable form of 
procedural encoding. Flowcharts and 
flowchart schemas (especially those 
that include dataflow as well as con¬ 
trol flow) introduce the idea of 
programming-language inde¬ 
pendence. 

Logic can express even the most 
diffuse cliches in a declarative fash¬ 
ion. However, because of the weak¬ 
ness and inefficiency of current 
automatic theorem provers, pure 
logic is not sufficiently machine 
manipulate to serve as the sole rep¬ 
resentation for programming cliches. 
Data abstraction approaches com¬ 
bine program schemas (to specify 
abstract operations) with logic (to 
specify data structure invariants). 

Goal and plan representations are 
used to explain the structure of pro¬ 
grams at a deeper level than source 


text. This information is essential if 
an automatic programming system is 
to explain its actions. 

Program transformations 8 incor¬ 
porate ideas from program schemas, 
macros, and logic. As discussed in 
the subsection on transformational 
methods, a transformation has three 
parts: a pattern (which is essentially 
a program schema), a set of logical 
applicability conditions, and an 
action (which is essentially a macro). 

The Plan Calculus 11 combines ideas 
from many of the representations 
described above. It achieves 
programming-language independ¬ 
ence through the use of dataflow and 
control-flow notions from flowchart 
schemas, it uses aspects of logic 
and data abstraction to represent 
data invariants and other diffuse 
aspects of cliches. It uses goals and 
plans to keep a record of the design 
decisions in a program. And, it 
includes the concept of language- 
independent, bidirectional program 
transformations, which link pairs of 
flowchart schemas. 

None of the representations above 
is completely satisfactory. If auto¬ 
matic programming systems are to 
continue to improve, representations 
must be developed that are both eas¬ 
ier to manipulate and capable of 
representing aspects of program¬ 
ming knowledge (such as efficiency 
information) that are not readily cap: 
tured by any current formalism. 


Subroutines 

I 

Program 

Flowcharts schemas 



Procedural 

encoding 



ter file system and deadlock free are high 
level and diffuse. 

Representing and using such a wide vari¬ 
ety of cliches in an automatic program¬ 
ming system is a major challenge. The 
following are the main desiderata for a 
suitable knowledge representation: 
Expressiveness —The representation 
must be able to express as many differ¬ 
ent kinds of cliches as possible. 
Convenient combination—The methods 
of combining cliches must be easy to 
implement, and the properties of com¬ 
binations should be evident from the 
properties of the parts. 

Semantic soundness —The representa¬ 
tion must be based on a mathematical 
foundation that allows correctness con¬ 
ditions to be stated. 

Machine manipulability —It must be 
possible to manipulate the representa¬ 
tion effectively using computer tools. 
Programming-language independence 
—The representation should not be tied 
to the syntax of any particular program¬ 
ming language. 

\ In light of this “wish list,” an accom¬ 
panying sidebar discusses the various 
representations developed to date for pro¬ 
gramming cliches. 


Commercially available 
systems 

Academic research in automatic pro¬ 
gramming has focused on developing tech¬ 
niques that can support broad-coverage, 
fully automatic programming. Unfor¬ 
tunately, while this research points toward 
long-term progress, it has not yet had very 
much impact on commercial systems. 

Work in the commercial arena has 
focused on more modest goals and has 
been able to make significant steps toward 
automatic programming based on proce¬ 
dural methods. In particular, development 
has quickened over the last few years with 
the introduction of so-called computer- 
aided software engineering, or CASE. 

Database query systems. Perhaps the 
greatest commercial automatic program¬ 
ming success story has been the develop¬ 
ment of database query systems (for 
example. Information Builders’ Focus). 
These systems have limited capabilities 
and are not suitable for complex applica¬ 
tions. However, they allow end users to 
retrieve information from a database and 
produce customized reports without the 
help of programmers. 
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Within their narrow domain of applica¬ 
bility, database query systems are both 
end-user oriented and fully automatic. In 
simple applications, these systems have 
taken over completely, making automatic 
programming an everyday reality. 

Fourth-generation languages. Follow¬ 
ing the bottom-up approach to automatic 
programming, a number of commercial 
systems have been introduced that achieve 
a broader range of coverage than database 
query systems. They do this by sacrificing 
end-user orientation. Most such systems 
offer a combination of special-purpose 
interfaces (such as screen painters and 
report generators) and a very high level 
language designed specifically for business 
data processing applications. Systems that 
execute their languages interpretively, such 
as Applied Data Research’s Ideal and 
Software A.G.’s Natural, are typically 
called fourth-generation languages. 

Fourth-generation languages are used to 
some extent at perhaps ten thousand sites. 
However, though there is great enthusiasm 
about their potential, fourth-generation 
languages are far from displacing Cobol. 
This is because they are relatively ineffi¬ 
cient and cannot be used conveniently in 
conjunction with preexisting applications. 

Program generators. Program genera¬ 
tors, such as Transform Logic’s Trans¬ 
form and Pansophic Systems’ Telon, are 
very similar to fourth-generation lan¬ 
guages except that instead of operating 
interpretively, they generate Cobol code. 
In exchange for this increase in efficiency, 
program generators must settle for sup¬ 
porting a narrower range of features. 

Program generators are used at approx¬ 
imately a thousand sites. Although more 
efficient than fourth-generation lan¬ 
guages, their acceptance is limited by their 
narrower focus and by the difficulty of 
using them in conjunction with preexisting 
code. 

High-level design aids. Graphical tools, 

such as TnHpy Tprhnnln^y’*: Rvnplpratnr 

that support high-level software design 
methodologies take a different tack. These 
systems support the manipulation of high- 
level designs .without being able to gener- 
ate executable code. High-level3esign 
aids, therelore, exemplify the assistant 
approach^ to automatic programming 
rather than the bottom-up approach. 

Tools of this general type are used at 
r severa l-t housand sites an d are rapidlj\ 
becoming a standard parfot the f lTog i am-1 


ming process. However, their acceptance 
is slow because they lack integration with 
other tools and they leave code generation 
to the user. 

Project management tools. While con¬ 
sidering the assistant approach to auto¬ 
matic programming, we should also point 
out the growing capabilities of project 
management tools. These tools provide 
relatively modest but significant support 
for managing the programming process. 
For example, products such as BIS 
Applied Systems’ BIS/IPSE and Imperial 
Software Technology’s ISTAR provide 
facilities for breaking down a project into 
tasks and tracking their progress, both for 
configuration and version control and for 
the generation of various kinds of 
documentation and management reports. 

If in-house tools are counted, program¬ 
ming management aids are rapidly on the 
way to becoming the norm rather than the 
exception in large projects. Assuming that 
automatic programming is unlikely to 
make the problems of managing cooper¬ 
ative work disappear, the need for such 
tools will continue. 

Very high level prototyping languages. 

The one place where academic research 
has significantly affected commercial sys¬ 
tems is in very high level prototyping lan¬ 
guages. These languages represent a 
compromise between desires and reality; 
while researchers would like to create 
extremely high level languages that could 
be compiled into efficient code, it is not yet 
possible—even with significant sacrifices 
in the language—to create production- 
quality code. The current status of general- 
purpose, very high level prototyping lan¬ 
guages is typified by Reasoning Systems’ 
Refine, 5 which is based on research 
initiated at Stanford University. Prolog, 3 
which is based on logic-programming 
research at Imperial College, is also being 
used as a very high level prototyping 
language. 

The exact extent of very high level pro¬ 
totyping language usage is not clear. How¬ 
ever, it probably does not exceed a 
hundred sites. Acceptance of this 
approach is currently limited by the fact 
that rapid prototyping as a methodology 
is far from universally accepted. 

On the horizon 

Over the next several years, progress 
toward automatic programming will 


almost certainly follow the course set by 
currently available systems. Although con¬ 
ditions point to relatively rapid progress in 
CASE tools, radical breakthroughs seem 
unlikely. Rapid progress is possible 
primarily in the ways in which currently 
available systems are used. 

Technological advances. The quality of 
commercially available programming 
tools should improve markedly in the next 
few years. In particular, high-level design 
aids (for example, Texas Instruments’ 
IEF) will be extended to generate executa¬ 
ble code in many situations. Fourth- 
generation languages and program gener¬ 
ators will add support for slightly higher 
level constructs and somewhat less narrow 
domains of applicability. In addition, 
there will be a general trend toward greater 
integration of programming tools. With 
any luck, these incremental improvements 
should be enough to promote most of 
these tools from experimental use to full- 
scale acceptance. 

The developers of very high level pro¬ 
totyping languages, such as Refine, are 
strongly committed to increasing the effi¬ 
ciency of the code produced. Some ineffi¬ 
ciency is more or less incidental and will 
undoubtedly be eliminated. However, 
other problems are intrinsic to the 
approach: The whole point of very high 
level languages is to write a program using 
algorithms oriented toward clarity rather 
than efficiency, and since clear algorithms 
are often very inefficient, efficiency often 
requires radical changes. Unfortunately, 
no one knows how to identify such 
changes automatically or how to take 
advice on the subject effectively. 

To date, essentially all commercializa¬ 
tion of automatic programming research 
has been via the very high level language 
approach. However, we will soon begin to 
see the first commercialization of research 
on the assistant approach. For example, 
Bachman Information Systems is develop¬ 
ing a programming assistant product 
based in part on research at MIT. 

Rapidly decreasing prices for worksta¬ 
tion and database hardware provide an 
important opportunity. Soon, a threshold 
will be reached where it will be practical to 
capture on line all the intermediate work- 
products of the programming process, 
whether produced manually or automati¬ 
cally. Besides being intrinsically beneficial, 
this will drive further automation. 

Basic research on automatic program¬ 
ming is very much like cancer research: A 
host of fundamental problems remain to 
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be solved. Therefore, it is highly unlikely 
that anyone will discover a ‘ ‘ silver bullet ’ ’ 
that will remove all obstacles to the rapid 
development of general-purpose auto¬ 
matic programming. However, research¬ 
ers will continue to chip away at the 
problem from many directions. 

Management changes. Progress in any 
kind of automation is always obstructed 
by management problems as much as by 
technological hurdles. At least four major 
changes must occur at the management 
level if the potential of automatic pro¬ 
gramming is to be realized. 

First, we must recognize that capitaliza¬ 
tion for programming needs to be 
increased. In most organizations, a dollar 
spent on additional computer hardware or 
programming tools will bring significantly 
more benefits than a dollar spent on addi¬ 
tional programmers. (Studies have shown 
that significant productivity gains can be 
obtained merely by giving programmers 
offices with doors!) 

Second, given that the heart of auto¬ 
matic programming is reuse, economic 
incentives in software development and 
acquisition need to be revised to foster 
reuse. Under current contracting practices, 
there is often an economic incentive 
against software reuse and the production 
of easily maintainable software. 12 Policies 
whereby contractors would increase their 
profit by reusing software developed by 
others—or were paid extra if they 
produced something that someone else 
reused—would be steps in the right direc¬ 
tion. It would also be a good idea to tie 
some part of profit to the long-term costs 
of the delivered software. 


Third, management must recognize that 
the only way to reduce the lifetime costs of 
software is to spend more supporting the 
early parts of the process—requirements 
definition, specification, and design. For 
example, people often talk about software 
reuse as if it were some miraculous way to 
reuse code that has already been written. 
In fact, there is no way to reuse software 
unless it is carefully designed to be reusa¬ 
ble. This pays big dividends, but it requires 
significant “up-front” expenditures. 

Finally, as with all automation, the real 
promise of automatic programming is not 
just in automating what is done now but 
in completely changing the way things are 
done. In the case of office automation, for 
example, it pays to redesign the whole 
information flow in the office rather than 
put the same old paper forms into an elec¬ 
tronic medium. With programming, this 
means reexamining the traditional model 
of the software life cycle, which is begin¬ 
ning to happen with the increasing accep¬ 
tance of prototyping. It also means 
breaking down conventional distinctions 
between languages, environments, and 
interfaces, which is occurring in the form 
of graphical interfaces and object-oriented 
programming. 


A utomatic programming in the 
form of compilers for high-level 
languages became available in 
the late 1950s. By the late 1960s, it was 
clear that the next logical step was to move 
up to very high level languages. However, 
this step turned out to be much more dif¬ 
ficult than expected, and progress on the 
bottom-up approach to automatic pro¬ 


gramming was essentially stalled during 
the 1970s. 

The main focus of work on automatic 
programming in the 1970s switched to the 
narrow-domain approach. Since then, a 
variety of systems, such as database query 
languages, have been constructed that 
deliver end-user-oriented, fully automatic 
programming in small domains. 

In the 1980s, interest has returned to the 
bottom-up approach. This has led to the 
appearance of very high level prototyping 
languages. In addition, we have seen the 
arrival of fourth-generation languages and 
program generators that are more narrow 
in their focus as well as more efficient. The 
1980s have also seen increased interest in 
the assistant approach to automatic pro¬ 
gramming in the guise of high-level design 
aids and other advanced programming 
tools. 

A further look into the future reveals no 
sign of the cocktail party version of auto¬ 
matic programming. However, there will 
be significant evolutionary progress. With 
luck, we will be saying much the same 
thing about automatic programming in 
1998 that we said in 1958—that it has 
improved programmer productivity dra¬ 
matically and has further reduced the dis¬ 
tinction between programmers and end 
users. □ 
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SPECIAL REPORT 


The 1986-1987 Taulbee Survey 

David Gries and Dorothy Marsh 
Cornell University 


T his report describes the results of 
a survey completed in December 
1987 on the production and 
employment of PhDs and faculty of PhD- 
granting computer science/engineering 
departments during the academic year 
1986-87.* * All 123 computer science 
departments (111 US and 12 Canadian) 
participated. In addition, for the first time, 
22 US departments offering the PhD in 
computer engineering were included.** 
Throughout this report, computer 
engineering (CE) statistics are reported 
separately so that comparisons with previ¬ 
ous years can be made for computer 
science (CS), but the intention is to merge 
all statistics for CS and CE after several 
years. 

Some highlights from the survey are 
• The 123 CS departments produced 
466 PhDs, an increase of 13 percent over 
the previous year; 255 were Americans, 19 
Canadians, and 181 foreign (11 were 
unknown). Of the 466,232 went to acade¬ 
mia, 151 to industry, 8 to government, and 
34 overseas; 4 were self-employed (37 were 
unknown). 

• The 123 CS departments expect to 
produce 707 PhDs next year. (This is far 
too optimistic; we expect, instead, another 
increase of 13 percent to 525.) 

• 1,008 students passed their PhD 
qualifying exam in CS departments, an 
increase of 17 percent over 1985-86. 

• The 123 CS departments have 2,269 
faculty members, an increase of almost 11 
percent: 857 assistant, 630 associate, and 
782 full professors. 



The Computing 
Research Board’s 
survey on production 
and employment of 
computer science and 
engineering PhDs and 
faculty now includes 
departments offering 
PhDs in computer 
engineering. 


The title of the survey honors Orrin E. Taulbee of the 
University of Pittsburgh, who conducted these surveys 
for the Computer Science Board annually from 1970 


*A total of 123 departments reported on an academic- 
year basis and 13 on a 1987 calendar-year basis; nine 
neglected to indicate the system used. Departments 
usually report on the same basis from year to year, so 
the difference has no effect when viewing changes in 

**The Forsythe list — the list of all departments in the 
US and Canada that grant a PhD in computer science 
or computer engineering — is maintained by Terry 
Walker, a member of the Computing Research Board. 
This is the first year that the Computer Engineering 
Departments have been included. 


• The 123 CS departments reported hir¬ 
ing 238 faculty and losing 179 (to retire¬ 
ment, death, other universities, graduate 
school, and nonacademic positions). 

• The 123 CS departments expect to 
grow from 2,325 faculty members (includ¬ 
ing visitors and non-tenure-track faculty) 
to 3,133 in five years, an increase of 35 per¬ 
cent, at an average rate of 1.3 per depart¬ 
ment per year. (Last year, they expected a 
growth of 1.4 members per department 
but grew by 1 per department.) 

One can draw some conclusions and 
make some predictions. First, the growth 
of 13 percent in CS PhD production, 
although less than the 20-percent increase 
of 1985-86, is encouraging. Because of the 
increase in PhD qualifying exam passage, 
this growth is expected to continue. We 
can expect 600 PhDs per year by 1991. 

The field continues to be far too young 
and inexperienced, a problem that only 
time will solve. CS continues to have more 
assistant professors than full professors, 
which puts an added burden on the older 
people. In fact, the ratios of assistant and 
associate professors to full professors has 
not changed appreciably in three years. No 
other field, as far as we know, has this 
problem — in fact, most scientific fields 
are 80- to 90-percent tenured in many 
universities. The CE departments have 
more full professors than assistant profes¬ 
sors, mainly because many are older EE 
departments offering CE degrees. 

The increase in PhD production over 
last year reportedly consists entirely of US 
citizens, and the percentage of CS PhDs 
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Table 1. Titles of departments.* 


Number 

Title 

91 

Computer Science(s) 

17 

Electrical and Computer 
Engineering 

11 

Computer and Informa¬ 
tion Science(s) 

6 

Electrical Engineering and 
Computer Science 

6 

Computer Science and 
Engineering 

2 

Computer Engineering 

2 

Electrical Engineering 

2 

Information and Com¬ 
puter Science 

1 

Advanced Computer 

Studies / 

1 

Applied Sciences / 

1 

Computational Science 

1 

Computer Science and \ 
Electrical Engineering V 

1 

Computer Engineering and 
Information Science 

1 

Computer Engineering and 
Science 

1 

Computing Science 

1 

Mathematical Sciences 


Instead of “department,” the terms “center,” 
“division,” “program,” and “school” were each 


given to foreign students fell from 46 to 40. 
Whether this is a trend remains to be seen. 

Last year, 118 PhD-granting CS depart¬ 
ments were identified; this year, 123. The 
growth in the number of such departments 
is slowing down and, we believe, will soon 
essentially halt. The Computing Research 
Board was able to identify 33 departments 
giving a PhD in CE (but not in CS), and 
they were asked to participate in this sur¬ 
vey. Whether there will be more growth in 
CE departments is not known. 


Some methodological 
comments 

Questionnaires were sent to 123 CS 
PhD-granting departments and 33 CE 
PhD-granting departments in late October 
1987. (The titles of the departments appear 
in Table 1). 

With the help of 268 phone calls, all 123 
CS departments and 22 of the 33 CE 
departments had completed the question¬ 


naire by December 10, 1987. Thus, the 
figures in this report are complete for CS. 
We hope to have a better response from 
the CE departments in next year’s survey. 
The accuracy of this report depends, of 
course, on the accuracy with which the 
questionnaires were filled out by the indi¬ 
vidual departments. The new electrical 
engineering departments issuing PhDs in 
CE found it more difficult to complete the 
questionnaire, since they were asked to 
give information only on the CE part of 
their departments, and the required infor¬ 
mation was difficult to extract. 

As with most surveys, a small part of the 
data in the survey was not filled in or obvi¬ 
ously was incorrectly entered. We took the 
liberty to adjust some figures and estimate 
a few others — for example, in a few cases, 
with 142 or 143 out of 145 departments 
reporting a figure in a field, we estimated 
that field for the others. Our goal was to 
make this report consistent, clear, and sim¬ 
ple, without modifying the overall results 
in any way. 

In some places, we analyzed the data for 
the higher ranked departments as com¬ 
pared to the departments that were ranked 
lower and unranked, using the 1980 survey 
by the National Research Council. 1 (We 
also included the two largest Canadian 
universities somewhere within the top 20.) 
The survey is now eight years old, and 
many changes have occurred in CS since 
then (for example, the emergence of over 
60 PhD-granting CS departments); 
nevertheless, this breakdown still provides 
some useful comparisons. 

From time to time throughout this 
report, in order to draw meaningful con¬ 
clusions about the growth of the field 
(using older surveys), we compared figures 
for the CS departments only, keeping 
figures for CE separate. Throughout this 
report, figures for 1984-85 are taken from 
the 1984-85 Taulbee Survey, 2 for 1985-86 
from the 1985-86 Taulbee Survey, 3 and 
for 1970-84 from the 1970-84 Taulbee 
Summaries. 4 The figures for 1970-84 may 
not be accurate since not all departments 
completed questionnaires at that time. 
Finally, for comparisons with graduate 
study in mathematics, figures are taken 
from the 1987 Annual AMS-MAA 
Survey. 5 


Data on students 

PhD production and its growth. The 

field of CS produced 466 PhDs in 1986-87, 


an increase of 54 (13 percent) over 1985-86 
and an increase of 236 (103 percent) over 
1980. The figures on PhD production for 
CS and CE, as well as for qualifying-exam 
passage and sizes of incoming classes, are 
given in Table 2. In the column headed 
“No. of depts.,” the first number is the 
number of departments reporting and the 
second the total number of known PhD- 
granting departments. 

Currently, CS produces more PhDs per 
department than math does, although CS 
has 18.5 faculty per department and math 
has 30.2. Further, let us consider only 
associate and full professors, as the 
producers of most of the PhDs. In CS, the 
average CS associate and full professor 
produced 0.33 PhDs in 1986-87; the aver¬ 
age math associate and full professor, 
0.18. 

As mentioned earlier, CS PhD produc¬ 
tion increased 13 percent this year and 20 
percent last year. Future growth is 
expected. Indeed, the 123 departments 
project 707 PhDs in 1987-88 — a 
52-percent increase. A more realistic esti¬ 
mate is another 13 percent, to 525. As 
some evidence for our estimate, in the last 
survey the departments optimistically 
predicted 652 PhDs, we predicted 480, and 
466 were produced. Future increases in 
PhD production are a matter of concern 
to the field. Estimates of the annual need 
for new PhDs range from 600 to over 
1,000, and the field is growing steadily to 
meet the need. However, growth in PhD 
production requires a commensurate 
growth in funding for research. 

In 1986-87, an average of 3.9 CS-CE 
PhDs were produced per department (see 
Table 3) with 27 departments producing 0, 
20 producing 1, 23 producing 2, and 25 
producing 3. Thus, 95 departments 
produced less and 50 departments more 
than the average. The 50 that produced 
more than the average —roughly one third 
of the departments— produced 75 percent 
of the PhDs. 

The group of 50 that was over the aver¬ 
age expects to increase its PhD production 
in one year by far less (115 or 28 percent) 
than the group that was under the average 
(164 or 116 percent). The expected growth 
has remained about the same for the group 
that was above the average (24 percent in 
both 1984-85 and 1985-86). But the 
predicted one-year growth by the group 
that was below the average was 167 percent 
in 1984-85,164 percent in 1985-86, and 116 
percent in 1986-87. 

In an effort to find different expected- 
growth patterns, the data for the groups of 
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departments in various rankings (accord¬ 
ing to the 1984-85 survey 1 ) is presented in 
Table 3. 

Twenty-two CS-CE departments had 15 
or more students passing the qualifying 


Table 2. PhD production and growth. 


examination; they accounted for 55 per¬ 
cent of the students passing the exam. 

Sex and minority status of the PhDs. 

Table 4 gives the figures on PhDs awarded 


to minority students and females. The 
figures are rather depressing from the 
standpoint of minority and female repre¬ 
sentation in the field. Table 5 shows the 
statistics since 1970, with the data before 



Year 

No. of 
depts. 

PhDs 

produced 

Average 
per dept. 

Qualifying 
exam passage 

Average 
per dept. 

New PhD 
students 

Average 
per dept. 

cs 

1980-81 


230 






cs 

1984-85 

103 (109) 

326 

3.2 

755 

8.21 

1177 

12 

cs 

1985-86 

117(118) 

412 

3.5 

858 

7.30 

1170 

10 

cs 

1986-87 

123 (123) 

466 

3.8 

1008 

8.19 

1430 

12 

CS-CE 

1986-87 

145 (156) 

559 

3.9 

1168 

8.05 

1621 

11 

Math 

1986-87 

259 (317) 

845 

3.3 






Table 3. PhD production by ranking in 1986-87. 


Rank 

PhDs 

produced 

Average 
per dept. 

PhDs 
next yr. 

Average 
per dept. 

Qualifying 
exam passage 

Average 
per dept. 

New PhD 
students 

Average 
per dept. 

CS (all) 

466 

3.8 

707 

5.8 

1008 

8.3 

1430 

11.8 

CS 1-12 

166 

13.8 

196 

16.3 

255 

21.2 

287 

23.9 

CS 13-24 

66 

5.5 

123 

10.3 

142 

11.8 

207 

17.3 

CS 25-36 

66 

5.5 

103 

8.6 

143 

11.9 

176 

14.7 

Other CS 

168 

1.9 

285 

3.3 

468 

5.5 

760 

8.9 

CE 

93 

4.2 

131 

6.0 

160 

7.3 

191 

8.7 


Table 4. Sex and minority status of the PhDs. 


PhD minority status 

Male 

CS 

Female 

Total 

Male 

CE 

Female 

Total 

Male 

CS-CE 

Female 

Total 

White, not of hispanic origin 

263 

39 

302 

46 

2 

48 

309 

41 

350 

Black, not of hispanic origin 

1 

0 

1 

2 

0 

2 

3 

0 

3 

Hispanic 

8 

0 

8 

1 

0 

1 

9 

0 

9 

Other 

143 

12 

155 

41 

1 

42 

184 

13 

197 

Total 

415 

51 

466 

90 

3 

93 

505 

54 

559 


Table 5. Sex, minority status, and citizenship of PhDs since 1970. 


Year 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

84-85 

85-86 

86-87 

Total 

112 

124 

206 

208 

203 

256 

246 

208 

223 

248 

230 

235 

244 

256 

274 

326 

412 

466 

Female 

1 

4 

12 

7 

6 

21 

14 

14 

19 

24 

28 

26 

27 

31 

29 

32 

50 

51 

Percent 

1 

3 

6 

3 

3 

8 

6 

7 

9 

10 

12 

11 

11 

12 

10 

10 

12 

11 

Black 

1 

1 

2 

2 

2 

1 

0 

0 

2 

1 

0 

0 

1 

2 

3 

3 

6 

1 

Percent 

1 

1 

1 

1 

1 

0 

0 

0 

1 

0 

0 

0 

0 

1 

1 

1 

1 

0 

Hispanic 






No information available 






7 

6 

8 

Percent 
















2 

1 

2 

Foreign 

22 

21 

39 

41 

46 

68 

57 

68 

51 

65 

82 

79 

83 

86 

87 

122 

184 

181 

Percent 

20 

17 

19 

20 

23 

27 

23 

33 

23 

.26 

36 

33 

34 

34 

32 

37 

45 

40 
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1984-85 being taken from the 1970-85 
annual summaries. 4 Throughout the 
1980s the percentage of PhDs who are 
women has stayed relatively constant at 
about 11 percent, blacks at 1 percent, and 
Hispanics at 2 percent. 


Citizenship of the PhDs. The number of 
PhDs given to foreigners remained essen¬ 
tially the same (in CS, 184 last year and 181 
this year). Hence, the increase in PhD 
production was all in American and Cana¬ 
dian citizens, and the percentage of PhDs 


to foreigners dropped from 46 percent to 
40 percent. Figures for citizenship of the 
PhDs are given in Table 6. Table 5 con¬ 
tains the figures for foreigners from 1970 
to 1987. 

Employment of the PhDs. As shown in 
Table 7, in CS, 35 percent of the PhDs 
produced took positions in the US or 
Canada outside academia, 54 percent took 
faculty positions in the US or Canada, 8 
percent took positions in other countries, 
and 8 percent were unknown. There is lit¬ 
tle change from last year, when the figures 
were 42 percent, 48 percent, and 9 percent. 

Undergraduate and master’s degrees. 

Many universities and colleges have under- 


Table 6. Citizenship of PhDs. 



US 

Canadian 

Foreign 

Percent foreign 

Unknown 

CS 

255 

19 

181 

40% 

11 

CE 

41 

0 

46 

53% 

6 

CS-CE 

296 

19 

227 

42% 

17 


Table 7. Employment of the PhDs. 


Number 
of PhDs 

Self 

employed 

PhD 

dept. 

Academia 
Not PhD 
dept. 

Not CS 
or CE 

Industry 

Government 

Outside 
US and 
Canada 

Unknown 

CS 466 

4 

177 

41 

14 

151 

8 

34 

37 

CS-CE 559 

4 

194 

44 

19 

183 

18 

39 

58 


Table 8. Undergraduate and master’s degrees. 


Non-PhD degrees, 

PhD departments only 

84-85 

Undergraduate 
85-86 86-87 

87-88 

84-85 

Master’s 
85-86 86-87 

87-88 

CS 

Number of degrees 

10422 

10947 

10540 

10247 

2889 

3720 

3614 

3751 


Number of depts. responding 

96 

116 

121 

120 

101 

116 

123 

122 


Average per dept. 

109 

94 

87 

85 

29 

32 

29 

31 

CE 

Number of degrees 



2103 

2147 



731 

787 


Number of depts. responding 



22 

22 



22 

22 


Average per dept. 



96 

98 



33 

36 

CS-CE 

Number of degrees 



12643 

12394 



4345 

4538 


Number of depts. responding 



143 

142 



145 

144 


Average per dept. 



88 

87 



30 

32 


Table 9. New graduate students in fall 1987. 


New 

graduate 

students 


Total new 
graduate 
students 

With 

CS 

degrees 

PhD 

program 

Master’s 

only 

program 

Part-time 

master’s 

students 

Part-time master’s 
in departments 
with 6-50 students 

CS 

Total 

3644 

1621 

1430 

2083 

1078 

495 


Depts. responding 

121 

117 

121 

121 

120 

33 


Average per dept. 

30 

14 

12 

17 

9 

15 

CE 

Total 

952 

128 

191 

556 

481 

75 


Depts. responding 

22 

22 

22 

22 

22 

5 


Average per dept. 

43 

6 

9 

25 

22 

15 

CS-CE 

Total 

4596 

1749 

1621 

2639 

1559 

570 


Depts. responding 

143 

139 

143 

143 

142 

38 


Average per dept. 

32 

13 

11 

18 

11 

15 
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graduate and/or masters programs but do 
not award the PhD, so the data given 
below says little about the field of com¬ 
puter science as a whole. 

Table 8 gives statistics on undergradu¬ 
ate and master’s degrees in PhD depart¬ 
ments, with columns labeled “87-88” 
representing expectations. CS under¬ 
graduate degrees dropped 4 percent this 
year, and the departments expect another 
3 percent decrease next year. 

New graduate students in fall 1987. 

Table 9 gives enrollment figures for new 
students in fall 1987. In the table, “PhD 
program” stands for the number of new 
graduate students in PhD programs, 
regardless of whether they intend to earn 
a master’s degree first. The number of new 
graduate students in CS is down slightly 
from last year (from 3,722 to 3,644), but 
the number of new graduate students in a 
CS PhD program rose from 1,170 to 1,430 
(22 percent), another reason for expecting 
future growth in PhD production. 

The data for part-time master’s students 
needs some explanation. Fifty depart¬ 
ments had zero part-timers and 97 depart¬ 
ments had five or fewer. For these 
departments, the part-time master’s pro¬ 
gram may be inconsequential — perhaps 


just a small employee-degree program of 
the university. On the other hand, the two 
largest part-time master’s programs had 
205 and 152 new part-timers, respectively. 
The last column gives figures only for 
departments with between 6 and 50 new 
part-time master’s students. 

Table 10 gives the number of new PhD 
students in CS departments this year and 
last, with departments grouped by rank. 

Faculty 

Table 11 contains statistics on depart¬ 
mental faculty as of September 1987. In 
the table, all figures are listed in terms of 


full-time equivalents. For example, two 
half-time appointments count as one 
position. 

CS saw little change over last year in the 
proportions of faculty at the three levels. 
CS remains a relatively young field, with 
fewer full professors (6.4) than assistant 
professors (7) per department. The top 25 
departments have about the same number 
(10 and 9.9) of full professors and assistant 
professors per department. 

Hiring for 1987-88. The CS-CE depart¬ 
ments reported hiring 275 new faculty — 
1.9 per department. CS departments in the 
UShired211 —again, 1.9 per department. 
As shown in Table 12, salaries were 


Table 10. New PhD students in computer science departments. 


Departments 

Numbers of 
departments 

1985 

Total 

1986 

1987 

1985 

Average 

1986 

1987 

Ranked 1-12 

12 

349 

290 

287 

29 

24 

24 

Ranked 13-24 

12 

219 

176 

207 

18 

15 

17 

Ranked 25-36 

12 

144 

165 

176 

12 

14 

15 

All other 

62,81,85 

465 

678 

760 

8 

7 

9 


Table 11. Faculty statistics, 1987-88 academic year. 


Faculty 

All CS-CE depts. 
Total Average 

123 CS depts. 
Total Average 

Top 25 CS depts. 
Total Average 

Other 98 CS depts. 
Total Average 

Tenure-track faculty 

2,702 

18.6 

2,269 

18.4 

649 

26.0 

1,620 

16.5 

Assistant professor 

968 

6.7 

857 

7.0 

247 

9.9 

610 

6.2 

Associate professor 

765 

5.3 

630 

5.1 

153 

6.1 

477 

4.9 

Full professor 

969 

6.7 

782 

6.4 

249 

10.0 

533 

5.4 

Non-teaching research faculty 

140 

1.0 

126 

1.0 

69 

2.8 

57 

0.6 

Post-doctorates 

96 

0.7 

81 

0.7 

51 

2.0 

30 

0.3 

Non-tenure-track teachers 

473 

3.3 

390 

3.2 

95 

3.8 

295 

3.0 

Other faculty (e.g., visitors) 

281 

1.9 

201 

1.6 

60 

2.4 

141 

1.4 


Table 12. New PhD salaries for fall 1987. 



All US 
CS-CE depts. 

All US 

CS depts. 

Top 24 US 

CS depts. 

Other 99 US 

CS depts. 

12 Canadian 
CS depts. 

Total hired 

248 

211 

65 

146 

27 

Number of depts. reporting salaries 

83 

69 

18 

51 

7 

Minimum 

$35,000 

$35,000 

$37,333 

$35,000 

$38,500 

Average (of the averages) 

$40,885 

$40,840 

$41,540 

$40,592 

$42,440 

Maximum 

$52,100 

$48,000 

$47,000 

$48,000 

$48,578 


August 1988 


57 











reported for new PhDs hired for fall 1987 
by 83 US CS-CE departments, 69 US CS 
departments, and 7 Canadian depart¬ 
ments. The data for the Canadian univer¬ 
sities are shown separately in the table, in 
Canadian dollars. Canadian salaries are 
on a 12-month scale, Canadian and US 
dollars are different, and there are differ¬ 
ences in the amount of consulting (for 
extra income) that typically can be per¬ 
formed. 

The average US salary for a new PhD 
has increased from $36,668 in fall 1985 to 
$38,957 in fall 1986 (6.2 percent) to 
$40,885 in fall 1987 (4.9 percent). More 
information is included in Table 13, which 
shows the number of departments averag¬ 
ing a salary in each $1,000 range for fall 


1987 and two previous years (numbers are 
rounded and presented in thousands of 
dollars). 

The departments reported hiring 29 
faculty with PhDs earned in 1982 or later 
in a field other than computing 
science/engineering. The fields were 
mathematics (3), electrical engineering 
(21), sociology, philosophy, physics (2), 
and management sciences(3). Part of the 
increase of new faculty with electrical 
engineering degrees is due to the inclusion 
of the CE departments in this year’s 
survey. 

Faculty salaries. Table 14 summarizes 
nine-month faculty salaries in US depart¬ 
ments during the 1987-88 academic year. 


The second column of the table gives the 
number of faculty (in each rank) whose 
salaries were reported and, in parentheses, 
the total number of faculty in that rank. 

Departments reported the minimum, 
mean, and maximum salaries of assistant, 
associate, and full professors and the num¬ 
ber of faculty in each rank. For both mini¬ 
mum and maximum salaries, the table 
shows the minimum, average, and maxi¬ 
mum. Finally, the average is given over all 
salaries in each faculty rank — this is not 
the average of the means, but the true 
average. 

Comparing this year’s figures with last 
year’s, we find that the average assistant 
professor salary rose 6.1 percent from 
$39,544 to $41,945, the average associate 


Table 13. New PhD salaries for fall 1987 and two previous years. 


Salary (in thousands of dollars) 

35 36 37 

38 

39 

40 

41 

nn 

43 

44 

45 

46 

47 

48 

1985-86: Number of depts. 

2 10 11 

11 

5 

5 

1 

0 

0 

0 

0 

0 

0 

0 

1986-87: Number of depts. 

3 1 9 

11 

16 

14 

5 

4 

2 

0 

0 

0 

0 

0 

1987-88: Number of depts. 

1 1 1 

3 

8 

13 

14 

Uoj 

4 

1 

1 

0 

1 

1 


\ 20 / 4 1 1 


Table 14. Salaries, 108 out of 111 US computer science departments. 


Faculty 

rank 

Number 

Reported minimums 

Min. Mean Max. 

Average 
over all salaries 

Reported maximums 

Min. Mean Max. 

Assistant 

760 (772) 

$29,000 

$38,895 

$43,000 

$41,945 

$33,100 

$43,852 

$ 56,425 

Associate 

530 (535) 

28,311 

42,788 

57,882 

47,428 

36,700 

51,660 

66,640 

Full 

662 (675) 

34,483 

51,444 

72,420 

63,037 

46,200 

74,672 

125,000 


Table 15. Salaries, 12 of 12 computer science departments ranked 1-12, US only. 


Faculty 

rank 

Number 

Reported minimums 

Min. Mean Max. 

Average 
over all salaries 

Reported maximums 

Min. Mean Max. 

Assistant 

126 (126) 

$39,000 

$41,048 

$43,000 

$43,148 

$42,800 

$46,286 

$ 55,000 

Associate 

73 (73) 

28,311 

44,962 

55,000 

49,301 

45,783 

53,348 

61,900 

Full 

143 (143) 

34,483 

54,479 

71,400 

70,330 

73,377 

92,993 

125,000 


Table 16. Salaries, 11 of 12 computer science departments ranked 13-24, US only. 


Faculty 

rank 

Number 

Reported minimums 

Min. Mean Max. 

Average 
over all salaries 

Reported maximums 

Min. Mean Max. 

Assistant 

109(115) 

$39,000 

$40,674 

$43,000 

$42,987 

$43,000 

$46,388 

$55,492 

Associate 

65 (68) 

35,000 

45,979 

52,000 

51,544 

48,650 

57,449 

66,640 

Full 

82 (90) 

48,480 

53,510 

61,000 

65,813 

66,400 

84,461 

97,000 
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professor salary rose 5.3 percent from 
$45,062 to $47,428, and the average full 
professor salary rose 5.9 percent from 
$59,503 to $63,037. 

Tables 15-18 supply the same informa¬ 


tion as Table 14 but for departments 
grouped by rank. Table 19 gives salary 
information for the CE departments. 
Table 20 gives salary information for the 
11 Canadian departments that gave salary 


information. Table 21 gives the informa¬ 
tion for all US CS and CE departments. 

Five-year estimates of department 
growth. The departments were asked to 


Table 17. Salaries, 11 of 12 computer science departments ranked 25-36, US only. 


Faculty 

rank 

Number 

Reported minimums 

Min. Mean Max. 

Average 
over all salaries 

Reported maximums 

Min. Mean Max. 

Assistant 

97 (99) 

$37,100 

$40,499 

$42,000 

$43,307 

$37,100 

$45,849 

$ 45,109 

Associate 

54 (55) 

34,750 

45,633 

51,400 

51,112 

44,900 

53,945 

61,320 

Full 

68 (72) 

46,200 

54,146 

61,700 

66,970 

75,000 

87,793 

122,100 


Table 18. Salaries, 74 of 87 computer science departments ranked below 36 or unranked, US only. 


Faculty 

rank 

Number 

Reported minimums 

Min. Mean Max. 

Average 
over all salaries 

Reported maximums 

Min. Mean Max. 

Assistant 

428 (432) 

$29,000 

$38,007 

$43,000 

$41,017 

$33,100 

$42,739 

$ 56,425 

Associate 

337 (339) 

30,000 

41,547 

57,882 

45,779 

36,700 

50,168 

64,925 

Full 

369 (370) 

35,525 

50,209 

72,420 

58,869 

46,200 

68,118 

104,750 


Table 19. Salaries, 17 of 33 computer engineering departments, US only. 


Faculty 

rank 

Number 

Reported minimums 

Min. Mean Max. 

Average 
over all salaries 

Reported maximums 

Min. Mean Max. 

Assistant 

91 (110) 

$34,946 

$38,381 

$42,500 

$40,603 

$36,146 

$42,647 

$50,000 

Associate 

103 (128) 

35,600 

41,900 

48,700 

47,871 

39,800 

49,503 

56,000 

Full 

150(184) 

31,425 

47,216 

74,000 

54,907 

50,375 

67,722 

89,624 


Table 20. Salaries, 11 of 12 Canadian computer science departments (Canadian dollars). 


Faculty 

rank 

Number 

Reported minimums 

Min. Mean Max. 

Average 
over all salaries 

Reported maximums 

Min. Mean Max. 

Assistant 

75 (85) 

$37,674 

$41,620 

$48,000 

$44,958 

$42,518 

$48,241 

$55,300 

Associate 

91 (95) 

38,500 

48,299 

53,980 

54,766 

50,483 

60,659 

69,624 

Full 

91 (107) 

49,328 

58,677 

68,578 

69,625 

67,434 

81,108 

97,774 


Table 21. Salaries, 126 of 133 US computer science and computer engineering departments. 


Faculty 

rank 

Number 

Reported minimums 

Min. Mean Max. 

Average 
over all salaries 

Reported maximums 

Min. Mean Max. 

Assistant 

853 (883) 

$29,000 

$38,823 

$43,000 

$41,793 

$33,100 

$43,684 

$ 56,425 

Associate 

640 (670) 

28,311 

46,888 

57,882 

46,981 

36,700 

51,368 

66,640 

Full 

815(862) 

31,425 

50,920 

74,000 

61,456 

46,200 

73,810 

125,000 
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estimate their faculty sizes through 
1992-93, assuming an adequate supply of 
applicants (the lack of applicants has been 
a problem in the past). As shown in Table 
22, the 145 CS-CE departments would like 
a growth of 927 (33 percent) over the next 
five years. The 123 CS departments would 
like a growth of 808 (35 percent). Last year 
the 117 departments expected to grow by 
37 percent. 

Last year the 117 departments reported 
a desire to grow from 2,173 (18.6 per 
department) in 1986-87 to 2,387 (20.4 per 
department) faculty members by 1987-88. 
Nevertheless, this year the 123 CS depart¬ 
ments reported growing only to 2,325 (18.9 


per department). Table 23 indicates that all 
departments desire substantial growth, but 
with the most growth expected in the less 
well-ranked and in the smaller 
departments. 

The right half of Table 23 seems strange 
— it indicates that, in four of the groups, 
the average faculty size decreased from 

1986- 87 to 1987-88. The explanation is that 
there were six more departments in 

1987- 88, and these were rather small. Fur¬ 
ther, growth in a department from 39 to 
41, for instance, would move the depart¬ 
ment into the group 40-49, thus reducing 
the average department size in each of the 
groups 30-39 and 40-49. 


Faculty losses. As shown in Table 24, 
the academic research field of computing 
lost only 28 people through death or retire¬ 
ment, which is about 1 percent of the total 
number of faculty; CS lost 18 —the same 
as last year. This, together with the distri¬ 
bution of the faculty in the three ranks, 
emphasizes the extreme youth of the field. 
Of the other 188 CS-CE faculty who left, 
at least 40 percent left for other teaching 
positions, 25 percent left academia, 12 per¬ 
cent were visitors who returned to their 
employers, 2 percent returned to graduate 
school, and 8 percent left for other rea¬ 
sons. The percentages for CS were very 
similar: 44 percent are teaching elsewhere, 


Table 22. Desired faculty growth. 




1987-88 

1988-89 

1989-90 

1990-91 

1991-92 

1992-93 

5-year increase 

CS 

Faculty size 

2325 

2543 

2722 

2893 

3031 

3133 

808 

(35%) 


Average size 

18.9 

20.7 

22.1 

23.5 

24.6 

25.5 

6.6 

CS-CE 

Faculty size 

2806 

3055 

3269 

3460 

3616 

3733 

927 

(33%) 


Average size 

19.4 

21.1 

22.5 

23.9 

25.0 

25.7 

6.3 


Table 23. Average desired five-year growth in computer science departments. 




By rank 



By department size 


Per department 

1-12 

12-24 

24-36 

rest 

1-9 

10-19 

20-29 

30-39 

40-49 

Number of depts. 1987-88 

12 

12 

12 

87 

8 

67 

21 

12 

4 

Average dept, size 1986-87 

30 

25 

20 

16 

8 

15 

25 

34 

46 

Average dept, size 1987-88 

30 

26 

21 

16 

7 

14 

24 

34 

43 

Average dept, size 1992-93 

35 

32 

31 

22 

11 

21 

31 

39 

57 

Average five-year increase 

5 

6 

10 

8 

4 

7 

7 

5 

14 

Percent growth (projected) 

17% 

23% 

48% 

50% 

57% 

50% 

29% 

15% 

33% 


Table 24. Faculty losses. 



w/PhD 

CS-CE Depts. 
w/o PhD 

Total 

w/PhD 

CS Depts. 
w/o PhD 

Total 

Died or retired 

23 

5 ' 

28 

14 

4 

18 

Were visitors, returned to employer 

25 

1 

26 

19 

1 

20 

Teaching elsewhere 

82 

5 ' 

87 

73 

5 

78 

Left for non-academic position 

46 

7 

53 

38 

6 

44 

Returned to graduate school 

2 

3 

5 

2 

3 

5 

Other 

16 

1 

17 

13 

1 

14 

Total 

194 

22 

216 

159 

20 

179 
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25 percent took positions outside of acade¬ 
mia, 11 percent were visitors, 3 percent 
returned to graduate school, and 8 percent 
left for other reasons. The number of 
faculty who left the departments (179) is 
very close to the figure reported last year 
(174).□ 
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Computing as Conversation 


When it comes to education, it is 
amazing what doesn’t work. Consider 
television. I vaguely remember pro¬ 
tracted arguments between my father 
(who was pro-TV) and mother (anti- 
TV) about acquiring a television. My 
father eventually won with the argu¬ 
ment that television would be the 
greatest educational medium of all, and 
our education would suffer unless we 
had access to it. 

He was wrong. The educational pos¬ 
sibilities of television have not been 
realized. The education of the post¬ 
television generations actually might 
have suffered because of it. Were it not 
for a surprising excellence at the game 
Trivial Pursuit, I would say I learned 
nothing from my first 2,000 hours of 
television (apparently the people who 
make the game watched the same shows 
I did). 

Nor have I learned much from ency¬ 
clopedias, despite the fact that as an 
undergraduate student I sold the things. 
It just doesn’t figure. In spite of all 
those pages with all that data neatly 
arranged in context, countless Ameri¬ 
can families own 20-year-old sets of 
encyclopedias whose bindings still crack 
when opened. (The volumes are handy, 
however, to resolve disputes in Trivial 
Pursuit.) 

Ten years after my term as an ency¬ 
clopedia salesman I was introduced to 
“learning machines” by my daughter, 
who hated to go to school on Thursday 
because that was her day on the 
machine. The thing was unbelievably 
boring and, even to a first-grader, con¬ 
descending. The machines were so bad 
that if you did learn something from 
them you wished you hadn’t. 

Television, encyclopedias, and learn¬ 
ing machines: the great educational 
promise of these three technologies just 
hasn’t materialized. Something about 
learning makes it hard to design a tech¬ 
nology for it. You and I have learned 
endlessly from books, yet as soon as we 


try to systematically produce books for 
learning we write textbooks, which 
nobody reads unless they must, and 
encyclopedias, which are largely unused 
and therefore useless. We have also 
learned from using computers, but not 
from learning machines or programs 
specifically designed to teach us 
something. 

Why do we learn so much from cer¬ 
tain tools and so little from the things 
designed to teach us? Each of the many 
reasons points the way toward success¬ 
fully using the computer as a learning 
medium. The trick is understanding 
how we learn by using tools and then 
designing programs to foster that process. 

We learn from tools that excite us by 
extending our own capacities. For 
example, I encountered statistics several 
times in my own education. Statistics 
always seemed to involve copying 
columns of numbers, which I never did 
correctly, and then processing them 
according to a formula whose sense I 
invariably lost. Then I got a computer 
program that plotted statistics in three 
dimensions and rotated the plot. The 
program gave me a sense of pattern in 
the numbers I had never sensed before. 

I found myself dusting off old tables of 
data and shoving them through the 
program. 

I have seen people who displayed no 
graphical talent turn into creditable 
designers when exposed to computer- 
aided design programs. An architect I 
know lets his clients play with his 
designs on a CAD terminal. They 
change the design’s parameters, rede¬ 
sign the exterior, reroute ventilation 
ducts, etc., until they have a unique 
understanding of the design and its 
trade-offs. 

Excitement breeds its own explora¬ 
tion. The recent hyperbole about hyper¬ 
text has made much of the virtues of 
exploration. Hypertext reportedly lets 
the user explore a body of information 
in ways the encyclopedia never allowed. 


The user can follow paths through data 
along many logical levels at once— 
strings of definitions, descriptions, key 
words, and so on. 

But exploring a body of information 
through hypertext differs from the kind 
of exploration that comes from learning 
a new tool. As you explore the possibili¬ 
ties in a new CAD, econometric model¬ 
ing, or desktop publishing program, 
you explore your own capabilities. 
Implicit in learning new programs is the 
question, “I wonder what I can do with 
this thing?” You discover yourself, in a 
sense, as you discover the program. 

You push it to do things you have not 
seen before, secretly wondering if the 
program’s designer ever imagined it 
could be used the way you are using it. 
This type of exploration seems far more 
exciting and illuminating than the 
canned trips through a body of data 
imagined in hypertext (though perhaps I 
am jaded by my experience with ency¬ 
clopedias). 

This exploration is faintly subversive. 
For one thing, you can do it on the job. 
There you sit, discovering something 
about yourself, glimpsing the possibili¬ 
ties in yourself, and getting paid for 
doing it. Most employers say they are 
tickled to death when their employees 
learn something, but the employers 
usually have a very narrow idea about 
what is appropriate stuff to learn. Sit¬ 
ting at your computer, you are the mas¬ 
ter of your own explorations, at least 
until your productivity becomes embar¬ 
rassingly low. 

Perhaps the computer is not so much 
subversive as it is the basis for a merger 
between personal desires and institu¬ 
tional necessities. Discovering yourself 
through exploring the tools you use 
happens no matter what tools you use 
and almost whatever you use the tools 
for. Ideal productivity tools might be 
those that stimulate the greatest explo¬ 
ration and discovery in their users. 
Learning does not occur without some 
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level of self-discovery in the learner. 

I distinguish here between knowledge 
acquisition and learning. When you add 
a new record to a database, you do not 
say the database has learned something, 
even though it can tell you all about the 
record when asked. When people 
acquire information they can recite, 
they have no more learned than the 
database did. We often call that “learn¬ 
ing,” however, because it is closely 
related to real learning: the integration 
of new data into relationships with 
existing ideas and concepts. 

Acquiring information does not guar¬ 
antee that learning will happen; the new 
data might simply be stored someplace, 
failing to trigger connections and 
insights. Making the second part hap¬ 
pen requires effort by the learner. Some 
people learn automatically, as many 
teachers did when they were students. 
But so many people fail to learn at all 
that many teachers test only for data 
acquisition, afraid of what they would 
find if they presented a new problem to 
their students. Most testing is nothing 
more than database validation: “I put 
twelve new records in there; let me see if 
they are still there.” 

The major problem with traditional 
computer-aided instruction lies in its 
orientation toward data acquisition. 
Facts are drilled and tested until 
mastered. Worse, the medium itself 
inhibits the kind of self-discovery that 
lets students make the information their 
own. Such instruction offers no 
interesting questions to promote reflec¬ 
tion; no capacity for exploration, allow¬ 
ing the student to decide what to learn 
and in what order; no requirement that 
the person do more than master the 
data to pass the automated test. 

Traditional computer-aided instruc¬ 
tion has none of the educational quality 
that comes automatically from learning 
to use a computerized tool. Yet it need 
not be so. Instructional programs are 
tools in the same way productivity pro¬ 
grams are tools, and they should gener¬ 
ate the same sort of self-discovery. 

When we set out to design something 
educational, however, we think first of 
data or skill acquisition, of having lots 
of material that the textbook or instruc¬ 
tional program must cover. Instruc¬ 
tional materials direct people as nothing 
else does. Maybe we don’t learn very 
much when directed, particularly when 
a machine does the directing. 

An alternate way of using the com¬ 
puter to teach occurred to me when I 
spoke with a former student about a 
difficult problem he faced in practice. 
He had not been a promising student; 
his eyes glazed over the instant the class 
discussion reached any level of abstrac¬ 


tion. Searching for the meaning in 
things was to him a digression, and he 
had not paid tuition for digressions. 

The novel situation he asked me 
about was big trouble for him, calling 
for a unique approach and deep analy¬ 
sis. My initial impulse was to tell him to 
give the problem to someone else, but 
he seemed anxious to understand the 
problem. Our conversation ranged from 
microeconomic theory through episte¬ 
mology to distributive justice. He 
wanted more information and was 
pleased with his own understanding. 


Traditional 
computer-aided 
instruction has none of 
the educational quality 
that comes automatically 
from learning to use a 
computerized tool. 


This experience suggested the obvi¬ 
ous: people learn effortlessly when they 
need to. And when that time comes, 
everything is self-discovery. Even 
epistemology, which has convinced 
more students not to major in philoso¬ 
phy than any other subject, becomes 
fascinating at such a time—learning 
what it means to know something is 
interesting when you are trying to 
know something. 

The computer is innately geared to 
this sort of instruction. Discussions of 
the sort I had with my ex-student 
should be available on line. What I have 
in mind might be called “guided explo¬ 
rations.” Once the user has an idea of 
what he or she needs to know, the com¬ 
puter would lead the person through a 
discussion of what lies beneath the sur¬ 
face. The dialogue could connect seam¬ 
lessly to a hypertext exploration of an 
existing body of information, then back 
to the dialogue for further exploration. 

This type of computerized instruction 
would connect to the tools the person 
was using, much like help files in pres¬ 
ent applications. But, unlike help files, 
their design would be conversational. 
The programs would treat the user as 
someone who wanted to understand 
something, rather than someone with a 
deficiency to be remedied. And the pro¬ 
grams would deal, within limits, with 
whatever the user wanted to understand. 

We must change the way we think of 
the computer to realize its full potential. 
We tend to think of it.as a traditional 


tool that person A uses to do a job for 
person B. Person C, who designed and 
built the tool, sits somewhere in the 
background. Perhaps he or she included 
a handbook with the program, but 
essentially C is out of the picture. 

It’s that way with all traditional 
tools, isn’t it? Consider the disk sander. 
You buy it, read the booklet that comes 
with it, plug it in, and pull the trigger. 
And, if you are like me, you make a big 
mess out of the job; the sander claws its 
way across your work, leaving indelible 
swirls all over the place. This is not an 
easy tool to use. You learn only that 
you’re not very handy with a disk 
sander, and you don’t extend your 
capabilities a bit. You might abandon it 
or use it only for jobs that don’t matter 
if they look a mess. Or you might take a 
woodworking or metalworking course 
at the local high school, looking for 
someone who knows how to use the 
thing. 

You really need a conversation with 
person C, someone who can open your 
eyes to the disk Sander’s peculiarities 
and possibilities. Wisely used, you can 
do a lot with a disk sander. You just 
need a dash of disk sander wisdom (and 
maybe a demonstration). Most tool 
suppliers have abandoned the wisdom 
part altogether, giving you only a miser¬ 
able little booklet poorly translated 
from another language. 

Computerized tools differ greatly 
from previous hardware because they 
are at once both productivity tools and 
a powerful learning environment. We 
have not capitalized on the power of 
that learning environment because we 
think of computerized tools in the same 
way as traditional tools. Most programs 
contain help files, but they are usually 
no more than an on-screen version of 
the miserable little booklet that came 
with my disk sander. 

If we begin to think of tools as part 
of a relationship between those who are 
expert in doing a job and those who 
want to do the job, we will unlock the 
real possibilities of computerized tools. 
Viewed this way, the educational aspect 
of the tool is basic to it, not a help file 
hung on afterward. The tool could 
begin with a tutorial and progress 
through illustrations of prior uses, dia¬ 
logues about what the user wants to do, 
and a free-form exploration of the tool 
itself. The artist is never far away, 
always available to answer questions 
and trigger new uses of the tool. 

The computer is a unique communi¬ 
cations medium. Where electronic 
bulletin boards, e-mail, and the like are 
variations on the theme of the tele¬ 
phone, the computer application pro¬ 
gram establishes communication 
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between the person doing a job and 
those who understand that job. When 
operating the tool, the user is singularly 
open to others who can lead him or her 
to deeper understanding. 

We sometimes characterize science 
and philosophy as the Great Conversa¬ 
tions. The conversations are, of course, 
one-way—from past to present—but 
thinking of them as conversations is 
meaningful nonetheless. One learns 
from Newton not only how gravitation 
dawned on him, but also how he recog¬ 
nized it as a fertile idea and how he pur¬ 
sued it. 

Industrialization has not been a Great 
Conversation, at least not for the work¬ 
ers who were given tools and told what 
to do with them. A gulf existed between 
the job to be done and the meaning of 
that job. 

The computer creates the possibility 
of extending the Great Conversation to 
all who use it by engaging users with the 
insights of those who created the tools. 
Where industrialization divided educa¬ 
tion from production—dedicating the 
first twenty years of life to training and 
the next forty to production—the com¬ 
puter can reintegrate them. Learning 
vcgn^be an undifferentiated part of using 
and producing. 

Much money is spent on computer 
education, both on using the computer 
to teach job skills and on teaching peo¬ 
ple to use computers. That approach 
exemplifies industrial-age thinking: a 
chunk of education followed by 
production. Production and education 
should be inextricably intertwined. All 
but the few autodidacts among us 
generate the desire to learn and under¬ 
stand while we do a job or solve a prob¬ 
lem. Education should be available to 
us at that point. 

The educators of the Information 
Age will be the software designers, the 
system integrators, and the users of 
tools, not professional educators. The 
new educators must see the tools and 
systems they create as a form of com¬ 
munication with others, as part of an 
interaction with users who are trying to 
understand and expand their capacities. 

One day an article like this one might 
be one of the resources available to you 
on line as you sit down to design a piece 
of software or put together a system for 
other people to use, rather than a 
freestanding piece of print journalism 
(like this one) you read out of the con-, 
text it applies to. It will then be more 
meaningfully a conversation between 
two people trying to figure out how to 
use this technology more effectively. 

Hugh Gibbons 

Poseidon 
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IEEE Board approves Computer 
Society standards activities 


The following new Computer Society 
projects were approved by the IEEE 
Standards Board at its June 8 meeting: 

• P610.10, Glossary of Computer 
Hardware Terminology 

• P610.11, Glossary of Theory of 
Computation Terminology 

• P610.12, Glossary of Software 
Engineering Terminology (Revision 
of IEEE 729) 

• P610.13, Glossary of Programming 
Languages Terminology 

• P802.1D, MAC Sublayer Intercon¬ 
nection (MAC Bridging) 

• P802.1E, Load Protocol 

• P802.1F, Recommended Practices 
for the Development of IEEE 802 
LAN/Metropolitan Area Networks 
(MAN) Management Standards 

• P802.3G, Conformance Test Speci¬ 
fications 

• P802.3H, Layer Management 

• P802.3I, Medium Attachment Unit 
and Baseband Medium Specifica¬ 
tions, Type 10BASET 

• P802.5K, Token Ring Media Speci¬ 
fication 

• P802.6A, Standard for Multiple 
Port Bridging for Metropolitan 


The Software Engineering Institute 
has announced the formation of a com¬ 
mittee to describe a new method of 
interfacing Ada application programs 
and SQL database management sys¬ 
tems. The method is an extension of the 
Module Language described in the 
ANSI SQL standard document. 

The committee is composed of 
representatives of Ada compiler ven¬ 
dors, DBMS vendors, the government 
user community, and database and Ada 
experts. 

The committee will produce a docu¬ 
ment, tentatively entitled “Guidelines 
for the Use of the SQL Ada Module 
Extensions,” to describe the method so 


Area Networks (MAN) 

P802.10, Standard for Interopera¬ 
ble LAN Security (SILS) 

PI 178, Scheme Programming Lan¬ 
guage Standard 


• P959, I/O Extension Bus 

• P982.1, Dictionary of Measures to 
Produce Reliable Software 

• P982.2, Guide for the Use of the 
Dictionary of Measures to Produce 
Reliable Software 

• P1028, Software Reviews and 
Audits 

• P1096, Multiplexed High- 
Performance Bus Structure 

For more information on new and 
ongoing projects, or for assistance in 
purchasing copies of approved stan¬ 
dards, contact Richard Cain, Standards 
Coordinator, Computer Society, 1730 
Massachusetts Avenue NW, Washing¬ 
ton, DC 20036-1903, phone (202) 371-0101. 


interface method 


it is suitable for manual implementation 
with existing tools. 

Scheduled for release October 1, the 
document will discuss the database 
interface as seen by the application, as 
well as describe the construction of 
the interface. It will also serve as the 
output specification of tools that auto¬ 
mate construction of the interface. 

Persons who would like to serve in a 
review capacity in connection with the 
committee’s work are asked to contact 
Marc H. Graham, Software Engineer¬ 
ing Institute, Carnegie Mellon Univer¬ 
sity, Pittsburgh, PA 15213, phone (412) 
268-7784. 


Group formed to produce 
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Emerging trends present opportunities, 
challenges for standards development 

Howard L. Yudkin, Chief Operating Officer, Software Productivity Consortium 


A number of trends are emerging in 
software engineering that offer oppor¬ 
tunities for meaningful standards devel¬ 
opment. The trends are creating 
additional challenges for engineering 
standards developers. 

The area of software engineering is 
just beginning to grow out of its 
infancy. This growth is spurred in part 
by the maturation and growing dissemi¬ 
nation of basic, so-called modern pro¬ 
gramming practices. They include vari¬ 
ants of structured analysis for defini¬ 
tion of requirements or high-level 
design decomposition and methodolo¬ 
gies for organized management and 
documentation.^ 

With these techniques added to the 
evolution of programming languages 
with more precise syntax and stronger 
consistency properties, it is now possi¬ 
ble to develop higher quality, more 
maintainable software systems than in 
the past. The emergence of software 
tools that automate some features of 
these practices is a major aid in their 
use and dissemination. 


Systems demands grow. At the same 
time, the demand for much larger, more 
complex software systems continues to 
expand. Size and complexity of 
projects, such as the advanced technol¬ 
ogy fighter or the space station, dwarf 
anything imaginable even a few years 
ago. In fact, the explosion of demand 
has precipitated what many have 
described as a software crisis. 

A growing mismatch exists between 
demand and the ability of the software 
engineering industry to meet it, even 
with modern programming practices. 

This demand-supply gap is spurring 
the development of new software 
engineering approaches that emulate 
approaches in more traditional 
engineering disciplines. Important 
among these are techniques to identify 
and resolve implementation risks earlier 
in the development cycle and techniques 
to develop designs of software systems 
based on systematic use of standards 
parts. 

The former are referred to, perhaps 
inappropriately, as prototyping. Bread- 


An earlier version of this report appeared on 
pp. 40-41 of the June 20, 1988, edition of 
Computerworld Extra. 


boarding may be a better analogue for 
description. The latter are a form of 
software reuse. In practice, they are two 
sides of the same coin. 

Standard parts allow rapid assembly 
of prototypes that provide the bases for 
evolving final systems. The use of these 
techniques represents a departure from 
the basic so called “waterfall” develop¬ 
ment methods embodied in modern 
programming practices. 

But using them does not imply the 
abandonment of the benefits of these 
programming practices or the tools that 
have emerged to implement them. The 
newer engineering processes are gener¬ 
alizations of the older ones, and are bet¬ 
ter matched to larger, more complex 
systems. These newer processes offer 
many opportunities for development of 
standards to ease their practice. 


Parts and environments. Two obvi¬ 
ous areas of standards needs are those 
for the standard parts themselves and 
those for the development environments 
that would support their use. 

Design based on standard parts is a 
regular engineering practice in all tradi¬ 
tional engineering fields. The use of 
standard parts for most system design 
allows designers to concentrate new 
design efforts on those areas that have 
novel requirements or constraints. Typi¬ 
cally, these may be a small fraction, 
perhaps 10 to 20 percent, of the “mod¬ 
ules” of finally assembled systems. 

To be a true standard part, the part 
should be characterized by a “black¬ 
box” specification. The details of the 
construction should be opaque to the 
user. The external specification should 
be sufficient to uniquely characterize 
the part. 

This opaqueness is an example of the 
revered software engineering principle 
of information hiding. Given such a 
black-box specification, it would then 
be possible to catalog parts based on an 
identification system keyed to these 
specifications. 

Software parts catalogs to be con¬ 
structed would be directly analogous to 
catalogs of hardware parts. Standards 
for the forms of specifications and the 
parts identification systems would be 
necessary to permit widespread use of 
these parts. These are the standards that 
make the parts standard. 

It is also possible to envision a parts 
industry where suppliers build and pro¬ 


vide the standard software parts. These 
providers should be able to certify their 
products. That is, they should be able 
to guarantee that the part does indeed 
perform as its specification states. Stan¬ 
dard means of compliance testing are 
needed for certification. This situation 
also parallels that in the traditional 
hardware areas. 


Parts families recommended. To be 
useful, families of standard parts 
should evolve. These families should be 
able to be subsetted and expanded as 
use demands. Thus, standards for defi¬ 
nitions of useful families are also needed. 

The idea of families is not new. All 
that’s needed is to look at catalogs of 
standard screws to see the idea at work. 

A more relevant and richer example 
exists in computer hardware families. 
The idea matured with the IBM 360 
series and continues with today’s reuse 
of processor chips. 

The family concept already exists in 
software. The well-known software cost 
reduction method, developed at the 
Naval Research Laboratory, evolved a 
particular set of families of specifica¬ 
tions for software modules. 

Adoption of design using standard 
parts would require that software 
engineers give up their assertion that 
software is inherently more complex 
than hardware. Software part complex¬ 
ity grows exponentially with the time 
span of the part’s execution. Most, if 
not all, hardware parts possibilities 
have a continuum of values in any time 
frame. The hardware practice of 
approximating this continuum with 
finite families of standard parts is 
equally applicable to software. 


Standard interface properties. Stan¬ 
dard software parts should have stan¬ 
dard interface properties. These would 
permit the parts to be readily assembled 
and integrated into prototypes or even 
deployable systems. Such practice 
would make true rapid prototyping pos¬ 
sible. This would replace the current 
practice that is all too often simply a 
generalization of the idea of screen 
generation for management informa¬ 
tion systems. 

If the interface properties of parts are 
standardized, it may be possible to 
adapt or tune standard parts to change 
their individual performance without 
disrupting their integration properties. 
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Much of the desired revolution in 
software engineering could be achieved 
if ready access to standard parts was 
available. Early studies showed that 
improvements of factors of 2.5 to 3 in 
system development cost are quite feasi¬ 
ble in assembling single-system versions 
using standard parts. 

These factors account for the excess 
cost of developing a standard part and 
assume very modest levels of reuse. 
Given higher levels of reuse plus the 
decrease in numbers of versions 
required to obtain an acceptable final 
product with good rapid prototyping, 
major improvements in software pro¬ 
ductivity should be possible. 


The technology exists. Engineering 
standards for the parts are the obvious 
key to these improvements. Much of the 
technology needed for creating standard 
parts already exists. 

Ada packages might be good stan¬ 
dard parts. The generic feature permits 
a ready definition of families. The sepa¬ 
ration of specification and implementa¬ 
tion abets the desirable adaptation 
feature and a mechanism for building 
collections of standard ports from 
previously existing software routines. 
The strong typing feature assists in stan¬ 
dardizing interface properties. 

The Ada package example also 
exhibits the challenge in defining the 
right size for standard parts. Even a sin¬ 
gle line of Ada source code could be a 
standard part, although the package 
overhead would kill efficiency. 

On the other hand, too large a pack¬ 
age would imply a functionality too 
complex for ready reuse. Thus, some 
middle, yet-to-be-defined range of size 
is needed. 


Automated tools needed. An aspect 
of prototyping and design using stan¬ 
dard parts that should emerge from the 
discussion above is that they are compli¬ 
cated processes whose feasible uses 
require application of automated tools. 
Furthermore, these tools must commu¬ 
nicate with each other in integrated 
environments. 

Of particular importance is the inte¬ 
gration of project status and planning 
tool data with technical description tool 
data if the prototyping process is to be 
controlled for convergence. 

Configuration management or ver¬ 
sion control of the life cycle object in 
the prototyping process is also crucial. 
An array of tools and some standards 
for their data outputs are needed. 

Since it is unlikely that all the tools in 
a development environment would 
come from a single source, it is desira¬ 


ble and ultimately imperative that stan¬ 
dards for tool interfaces, data 
structures, and other elements in devel¬ 
opment environments emerge if such 
environments are to be easily configured. 

A software development environment 
is simply an application to which design 


using standard parts applies. The tools 
in the environment could be constructed 
with standardparts that ensure adherence 
to the environment interface standards. 
Here again, a major opportunity exists 
for software engineering standards 
development. 


Yudkin, Olisa keynote Compstan 88 


Howard Yudkin, CEO of the Soft¬ 
ware Productivity Consortium, and 
Kenneth A. Olisa, Wang vice presi¬ 
dent for marketing, were the respec¬ 
tive opening and closing keynote 
speakers at the 1988 Conference on 
Computer Standards in Arlington, 
Virginia. 

Roger Martin of the National 
Bureau of Standards served as 
general conference chair at Comp¬ 
stan 88, and Laurel Kaleda of IBM 
and James Hall of NBS were program 
co-chairs. 

In his talk, Yudkin discussed the 
economic impact and demands that 
affect standards development and 
use, while Olisa focused his com¬ 
ments on trade-offs between stan¬ 
dards implementation and 
technology advances. 

Compstan 88 was sponsored by 
the Computer Society in cooperation 
with the Technical Committees on 


Microprocessors and Microcom¬ 
puters, Computer Communications, 
Operating Systems, Software 
Engineering, Test Technology, and 
Design Automation, plus the Stan¬ 
dards Coordinating Committee. 

The conference’s objective was to 
explore the impact of standards and 
what must be done to use them 
advantageously. The program 
included a number of papers, nine 
panel discussions, and a tutorial, the 
latter presented by the Standards 
Coordinating Committee and devoted 
to the environment and procedures 
for developing standards within the 
IEEE. 

The conference proceedings, Com¬ 
puter Society order No. 791, are avail¬ 
able by writing to CS Press, Order 
Department, Terminal Annex, PO Box 
4699, Los Angeles, CA 90051, or by 
phoning (800) 272-6657 (in California, 
dial (714) 821-8380). 


Ad hoc group formed to examine 
rapid picture transmission 


X3, the Accredited Standards Com¬ 
mittee on Information Processing Sys¬ 
tems, has announced the formation of a 
new ad hoc committee on picture cod¬ 
ing. The ad hoc group is expected to 
soon become a task group under X3’s 
Technical Committee on Codes and 
Character Sets, X3L2. 

The organizational meeting of the ad 
hoc committee was held June 7-9, con¬ 
current with ongoing meetings of its 
parent committee. 

US efforts on image coding are evolv¬ 
ing within the existing X3 technical 
committee on coding as a result of sig¬ 
nificantly increased activity in both the 
International Standards Organization 


and the International Consultative 
Committee for Telegraphy and 
Telephony in areas dealing with image 
coding and image compression. 

Parties in the US interested in more 
rapid transmission of pictures now have 
increased opportunity to consider and 
influence these international efforts. 

The ad hoc committee will file US posi¬ 
tions with its ISO counterpart, 
SC2/Working Group 8. 

Persons interested in participating in 
the activities of the new panel and its 
anticipated successor task group are 
encouraged to contact Charles F. 
Touchton, IBM, 3405 W. Buffalo Ave., 
Tampa, FL 33607, phone (813) 878-3084. 
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BEFORE COMPSAC88 ATTEND: 

Two Days of Tutorials on Current Topics 


Monday, October 3, 1988 • 9:00 a.m.-5:00 p.m. 


Knowledge-Based Systems: 

A Unifying View 

Oscar N. Garcia 

Audience: Intended for software managers, software engineers, and 
knowledge engineers. 

Course Description: This seminar is intended as an overview of the 
current understanding of knowledge-based systems from basic prin¬ 
ciples to examples of successful applications. Its purpose is to lead 
the attendees to the common and generic aspects of the approach 
rather than to the specifics of any one system. A comparison of some 
commercial systems will be given, as prototypes representing spe¬ 
cific concepts. 

Course Outline: 

• The Fundamental Reasoning Behind Knowledge-Based Systems 

• The Role of Knowledge Engineering 

• Symbolic Processing, Matching and Logic Inference 

• Forward Chaining and Production Systems 

• Inference Networks and Backward Chaining 

• Dealing with Uncertainty 

• Structured Representations and Hybrid Systems 

• Brief Introduction to Logic Programming 

• Verification and Testing 

• Some Shells and Tools 

Oscar N. Garcia is a Professor of Electrical Engineering and Com¬ 
puter Science at The George Washington University. He was pre¬ 
viously Professor and Chairman at the University of South Florida 
where he established their Computer Science and Engineering Depart¬ 
ment. In addition to'his academic experience Prof. Garcia has con¬ 
sulted extensively for IBM, Honeywell, NSF, IDA, and other industrial 
and governmental agencies. He holds BSEE and MS degrees from 
NCSU and a PhD from the University of Maryland. He is a Fellow 
of the IEEE and AAAS, and a member of ACM, AAAI, and other 
professional organizations. His current research interests are in rule- 
based systems and parallel computation for AI. 


CASE: Computer-Aided Software 
Engineering 

Elliot J. Chikofsky 

Audience: Intended as an overview and introduction to the state of 
CASE technology for software engineers, analysts, project managers, 
team leaders, and managers of both MIS/DP and real-time devel¬ 
opment staffs. 

Course Description: Methods which can improve the practice of soft¬ 
ware and system development have been available for over a decade. 
Yet, they have not penetrated well into the daily practice of systems 
organizations. CASE technology changes the equation. Relying on 
readily available desktop computer technology, CASE environments 
make the general application of formal system development meth¬ 
ods practical and economical. The approach applies equally to 
improving development of both software and non-software compo¬ 
nents of systems. CASE environments provide facilities to support 
the developer's work throughout the life cycle, and give the project 
team analytic tools to ensure consistency, completeness, and confor¬ 
mance to standards. 

Course Outline: 

• Why CASE?: software crisis and productivity challenge; evolution 
of development methods for MIS/DP, real-time, and embedded 
systems. 

• CASE Technology: integration of enabling technologies; automa¬ 
tion of the software life cycle and development methods; how 
CASE changes the productivity equation; comparison with SDEs 
and IPSEs; opportunities for reliability engineering of informa¬ 
tion systems; what CASE isn’t. 

• Features of CASE Environments: key concepts; integration of 
software/system development tools; graphic workstations; central 
repository (project dictionary); completeness and consistency; rule 
enforcement; prototyping; code generation; workstation, LAN, 
server, and host configurations. 

• Demonstration of a CASE Environment. 

• Bringing in CASE: survey of the CASE marketplace; selection 
strategies; issues of tool introduction; costs and benefits. 

• Management Issues: productivity impact and measurement; how 
people (mis-)use tools; how tools changes the work environment; 
application of standards, including DoD Std 2167. 

■ Future Directions: opportunities for automated development; trends 
in the evolution of CASE environments; meaningful application 
of expert system technology; reverse engineering of existing systems. 

Elliot J. Chikofsky is Director of Research and Technology at Index 
Technology Corporation in Cambridge, MA. He also teaches grad¬ 
uate courses on Software Engineering and Database Management 
at Northeastern University. He is general chair of CASE '88, the Sec¬ 
ond International Workshop on CASE (July 1988 in cooperation with 
IEEE), and was guest editor of the CASE issue of IEEE Software in 
March. He has been a consultant in the area of applying software 
engineering tools since the late 70’s, and has served as chairman 
of the Productivity Tools and Technology Committee of the IBM 
user group Share. As senior research staff member of the Univer¬ 
sity of Michigan's ISDOS Project, he was responsible for the com¬ 
mercial development and enhancement of PSL/PSA and related 
software engineering tools, as well as pioneering the application of 
such tools in reverse engineering. 










Tuesday, October 4, 1988 • 9:00 a.m.-5:00 p.m. 


Software Reusability 

Peter Freeman 

Audience: Intended for software developers and managers. 

Course Description: To survey basic concepts, current practice, and 
research developments that relate to reusability. The presentation 
will evaluate the relative importance of different approaches, and 
give specific suggestions for setting up libraries, producing reusable 
workproducts, and obtaining the cooperation of managers and 
developers. 

Course Outline: 

• Fundamentals: basic concepts of reusability; central technical issues; 
central management issues; key economic concepts. 

• Current Practice: language approaches; libraries/catalogs; 
evolutionary improvements; software factories; portability. 

• Getting started: making evolutionary improvements; setting up 
a library; obtaining programmer support; obtaining management 
support. 

• Other approaches and issues: application generators; handbooks; 
standards. 

• Research directions: transformational approaches; domain- 
modelling paradigm; design representations. 

Peter Freeman is on the faculty of the Department of Information 
and Computer Science at the University of California, Irvine and 
is presently serving as Director of the Division of Computer and 
Computation Research at the National Science Foundation. He has 
been involved in the analysis, design, and construction of advanced 
computer applications and the training of software engineers since 
1961. His research activities have been concentrated in software design 
and analysis techniques and their application to the development 
process. Dr. Freeman is the author of Software Perspectives: The Sys¬ 
tem is the Message , Software System Principles, and numerous tech¬ 
nical papers. He has edited or co-edited several books including 
Software Design Techniques and Reusability. He was the founding 
editor of the McGraw-Hill Series in Software Engineering and 
Technology. He received his Ph.D. in computer science from Carnegie- 
Mcllon University. 


The Object-oriented Approach to 
Software Engineering 

Bertrand Meyer 

Audience: Intended for managers, software project leaders, software 
engineers, members of software engineering groups, and others 
interested in software quality. To fully benefit from this tutorial, 
attendees must have an appreciation of the problems involved in 
designing significant software systems in industry. 

Course Description: Object-oriented methods and tools open an excit¬ 
ing new route to software quality. This tutorial introduces the fun¬ 
damentals of object-oriented design and programming from a software 
engineering perspective, addressing concerns of utmost importance 
to managers and developers, including how to make software easier 
to change, more reusable, and more reliable. 

The full extent of object-oriented techniques (rather than scaled-down 
versions made popular by Ada and Modula-2) will be introduced: 
classes, assertions, disciplined exceptions, genericity, single and mul¬ 
tiple inheritance, polymorphism, redefinition, dynamic binding, 
inheritance-based typing, deferred classes. A number of design and 
programming examples will be presented. 

Course Outline: 

• Background: stumbling blocks in the search for software quality. 

• The initial step: reversing the viewpoint in system architecture. 

• Fundamental techniques: classes, objects, genericity, assertions, 
programming by contract. 

• Inheritance: Role for reusability and extendibility. The place of 
multiple inheritance. 

• Inheritance techniques: Redefinition. Polymorphism. Dynamic 
binding. 

• Object-oriented design: influence of the object-oriented approach 
on the software lifecycle. Common mistakes. Finding the classes. 
Structuring systems. Keeping track of reusable components. 

• Programming environment issues. 

• Object-oriented languages: An overvew. 

Dr. Bertrand Meyer is President of Interactive Software Engineering 
Inc., Santa Barbara. He has published numerous papers and four 
books on programming methodology, programming languages, for¬ 
mal specification, software engineering tools, supercomputer pro¬ 
gramming, object-oriented techniques and other software engineering 
topics. He designed the Eiffel object-oriented environment and a 
number of other software tools. 
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Tuesday, October 4, 1988 


6:00 p.m.-9:00 p.m. PreConference Reception. Grant Park Room 


Wednesday, October 5, 1988 


9:00-10:30 a.m. Opening Session (G-PW) Gold Room 
Welcome: Abe Peled -IBM, USA, Conference Chairperson 
Additional Greetings: Stephen S. Yau -University of Florida, USA, 
Steering Committee Chairperson. 

Program Overview: Wing N. Toy -AT&T Bell Laboratories, USA, 
Program Chairperson. 

Keynote address: AI AND THE SERVICE INDUSTRY: COMPUTER 
ASSISTED EMPLOYEES REPLACE EMPLOYEE ASSISTED 
COMPUTERS. Robert Flast -Vice-President of Technology and 
Strategy, American Express. 

10:30-11:00 a m. BREAK 

11:00 a.m.-12:30 p.m. FOUR PARALLEL SESSIONS 

Session G-1W. Gold Room: 

Panel Session 

CASE: WHAT HAVE WE LEARNED! WHERE ARE WE HEADED! 
Chairperson: E. J. Chikofsky -Index Technology, USA 
Panelists: J. Grochow -American Management Systems, USA; 

(. Jenkins -Imperial College, University of London, UK. 

Session W-1W, Windsor Room: 

LIFE CYCLE SUPPORT TOOLS 1 

Chairperson: M. Butler -Argonne National Laboratory, USA 
Installing Transactions in a Requirement Engineering Method; 

M. Hallmann -University of Dortmund, FRG 

Early and Not-so-early Prototyping - Rationale and Tool Support; 

B. Ratcliff -Aston University, UK 


Designing Software for Maintenance and Performance; R. P. 
Mikkilineni -AT&T Bell Laboratories, D. F. Utter -AT&T Network 
Systems, USA 

Session E-1W, Florentine Room: 

DATABASE TECHNIQUES 
Chairperson: H. Lam -University of Florida, USA 
Local Concurrent Error Detection and Correction in Data 
Structures Using Virtual Backpointers; C. C. Li, P. P. Chen, W. K. 
Fuchs -University of Illinois at Urbana-Champaign, USA 
Automatic Test Case Generation From Relational Algebra Queries; 
W. T. Tsai, D. Volovik, T. F. Keefe, M. Fayad -University of 
Minnesota, USA 

Preserving Autonomy in a Heterogeneous Multidatabase System; 

B. Holtkamp -University of Dortmund, FRG 

Session B-1W, Buckingham Room- 
KNOWLEDGE BASED SYSTEMS AND APPLICATIONS 1 
Chairperson: H. Teh -National University of Singapore, SINGAPORE 
A Knowledge-Based System Approach to the Development of a 
System Functional Requirement Specification Processor,- W. F. 
Bruno, G. Narayanaswami, M. Aoyama, C. K. Chang -University of 
Illinois at Chicago, USA 

Knowledge-Aided Engineering Environment for Design and 
Manufacturing; D. shin, F. Maryanski -University of 
Connecticut,USA 

Liaison: An Intelligent Rule Driven Interface for Software 
Engineering Environments,- I. S. Law -Concurrent Computer 
Corporation, USA 




































12:30-2:00 p.m. LUNCH BREAK 
2:00-3:30 p.m. FOUR PARALLEL SESSIONS 

Session G-2W, Gold Room: 

Mini-Review 

Chairperson: J. Staudhammer -University of Florida, USA 
NEW NEURAL DESIGN OF ALGORITHMS. B. Wah -University 
of Illinois at Urbana, USA 

Session W-2W, Windsor Room: 

Mini-Review 

Chairperson: K. Hashimoto -Fujitsu Limited, JAPAN 
INTEGRATED SYSTEMS FACTORIES. D. Morgan -The 
Information Engineering Directorate, UK 

Session F-2W, Florentine Room: 

Panel Session 

EXPERIMENTAL PARALLEL PROCESSING RESEARCH ON 
RECONFIGURABLE S1MD AND/OR MIMD COMPUTERS 
Chairperson: T. L. Casavant -Purdue University, USA 
Panelists: G. J. Lipovski -University of Texas at Austin, USA; 

J. G. Kuhl -University of Iowa, USAj S. A. Fineberg -Purdue 
University, USA 

Session B-2W, Buckingham Room: 

KNOWLEDGE-BASED SYSTEMS AND*APPLICATIONS 2 
Chairperson; T, S. Chow -AT&T Bell Laboratories, USA 
A Knowledge-Based Approach to Rapid Prototyping System; J. Tsai, 
M, Aoyama, Y.L, Chang -University of Illinois at Chicago, USA 
The Requirement Model in a Knowledge-Based Rapid Prototyping 
System; P. Chen, C. Chou -National Chiao-Tung University, 

Taiwan, CHINA 

A Knowledge-Based System for Multi-Layer Channel Routing; 

D. Vakil, M. R. Zargham -Southern Illinois University, USA 

3:30-4:00 p.m. BREAK 

4:00-5:30 p.m. FOUR PARALLEL SESSIONS 

Session G-3W, Gold Room: 

EXPERIMENTS WITH SOFTWARE ENGINEERING TECHNIQUES 
Chairperson: M. I. Thomas -Bull, France 
The Software Process Model; D. A. Gustafson, A. C. Melton, Y. Chen 
-Kansas State University, A. L. Baker, J. M. Bieman -Iowa State 
University, USA 


A Case Study in Cleanroom Software Engineering: The IBM 
COBOL Structuring Facility; R. C. Linger -IBM Corporation, H. D. 
Mills University of Florida, and Information Systems Institute, USA 
Aspects of Computer-Aided Configuration Management with KMS ; 
W. Faltenbacher -Siemens AG, West Germany, FRG 
Experiment Analysis of SIMD Recursive Digital Filtering on the 
PASM SystemPrototype,- M. J. McPheters, Jr. -Carnegie Mellon 
University, T. L. Casavant -Purdue University, USA 

Session W-3W, Windsor Room: 

METRICS AND QUALITY ASSURANCE 
Chairperson: M. Fagan -IBM, USA 

Models of Programmer Behaviour: A Comparative Study; J. Siddiqi, 

B. Khazaei -Polytechnic, UK 

A Comprehensive and Aggressive Quality Assurance Programas a 
Foundation for Improving Software Productivity,- M. M. Kim, W. R. 
Hall -Computer Sciences Corporation, USA 
A Generic Technique for Developing a Software Sizing and Effort 
Estimation Model; A. Kulkarni, J. B. Greenspan, D. A. Kriegman, 

J. J. Logan, T, D. Roth -TRW, USA 

An Efficient Method for Incremental Attribute Evaluation by Using 
Multi-Dependency; Q. Lu, J. Qian -Fudan University, CHINA 

Session F-3W, Florentine Room: 

RELIABILITY AND DISTRIBUTED SYSTEMS 
Chairperson: J. Cho -Korea Advanced Institute of Science, KOREA 
Model and Algorithms for Reliability-Oriented Task Allocation in 
Distributed Computer Systems with Rcdunduncy; S. M. Shatz, J.P, 
Wang -University of Illinois at Chicago, USA 
Executable Assertion Development for the Distributed Parallel 
Environment; B. M. McMillin, L. M. Ni -Michigan State 
University, USA 

Designing Parallel Algorithms from Forests and Multistage Graphs; 
G. H. Chen -National Taiwan University, M. Chern -National 
Tsing Hua University, Taiwan, CHINA 

Session B-3W, Buckingham Room: 

Panel Session 

OBJECT-ORIENTED TECHNIQUES 
Chairperson: W. T. Tsai -University of Minnesota, USA 
Panelists: R. Mikkilineni -US West, USA; R. King -University of 
Colorado, USA; B. Cox -Productivity Products International, USA 

5:30 p. m. Conference Reception: Rendezvous Area 


Thursday, October 6, 1988 


9:00-10:30 a.m. PLENARY PANEL |G-PT| Gold Room 

MANAGING SOFTWARE ENGINEERING TECHNOLOGY 

TRANSFER. Chairperson: M. Azuma -Waseda University, JAPAN 
Panelists: L. A. Belady -MCC, USA; D. Decker -GTE Laboratories, 
USA; S. Hanata -NTT, JAPAN; D. G. Morgan -The Information 
Engineering Directorate, UK; A. H. Pau -Anthony Pau and 
Associates, HONG KONG 

10:30-11:00 a.m. BREAK 

11:00 a.m.-12:30 p.m. FOUR PARALLEL SESSIONS 

Session G-4T, Gold Room: 

SOFTWARE APPLICATIONS 

Chairperson: D. Cerino -Rome Air Force Center, USA 
Rule-Based Compactor for ULSI/CAD Mask Layout; P. Hsiao, 

C. Y. Syau, W. Feng -National Taiwan University, Taiwan, CHINA 
A Hierachial Picture Coding Scheme; N. G. Bourbakis -George 
Mason University, A. Klinger -University of California Los 
Angeles, USA 


Statemate and Cruise Control: A Case 1 Study; S. L. Smith, S. L. 
Gerhart -MCC, USA 

Session W-4T, Windsor Room: 

DATA MODELS 

Chairperson: D. P. Smith -AT&T Bell Laboratories, USA 
Type Management System in the Nexus Distributed Programming 
Environment; A. Tripathi, S. Ong -University of Minnesota, USA 
A Data Model Supporting System Engineering, T, Batz -IITB, 
P.Baumann, D. Kohler -AGD, FRG 

Object-Oriented Database Support for Software Engineering; P. A. 
Drew -US West Advanced Technologies and University of Colorado, 

D. J. Moore US West Advanced Technologies, USA 

Session F-4T, Florentine Room: 

Panel Session 

SOFTWARE DEVELOPMENT FOR PARALLEL PROCESSING 
Chairpewrson: J. Cavano -Rome Air Development Center, USA 
Panelists: G. Fox -California Institute of Technology, USA; 

L. Russell -Computer Sciences Corporation, USA; E. Spafford 
Purdue University, USA; S. Miller -Amerst Systems, Inc., USA 







Session B-4T, Buckingham Room: 

LEARNING AND HEURISTIC FUNCTIONS 
Chairperson: O. Shigo -NEC Corporation, Japan 
Learning Heuristic Functions for Numeric Optimization Problems,- 
M. Lowrie, B. Wah -University of Illinois at Urbana, USA 
Heuristic Solutions for the General Maximum Independent Set 
Problem with Applications to Expert System Design; I. Chang, 

W. Shao, H. Teh -National University of Singapore, SINGAPORE 
Learning and Using Scripts About Seismic Events; K. Kandt, 

P. Yucnger -Teknowledge Federal Systems, D. Baumgardt 
-Ensco, USA 

12:30-2:00 p.m. LUNCH BREAK 
2:00-3:30 p.m. FOUR PARALLEL SESSIONS 

Session G-ST, Gold Room: 

Panel Session 

SOFTWARE RELIABILITY APPLICATIONS 
Chairperson: J. Musa -AT&T Bell Laboratories, USA 
Panelists: D. Christenson -AT&T Bell Laboratories, USA; 

G. Kruger -Hewlett-Packard Corporation, USA; M. R. Garzia 
AT&T Bell Laboratories, USA; M. Bush -Jet Propulsion 
Laboratory, USA 

Session W-5T, Windsor Room: 

Panel Session 

SOFTWARE DEVELOPMENT ENVIRONMENT 

STATE-OF-PRACTICE 

Chairperson: S. L. Gerhardt -MCC, USA 

Session F-5T, Florentine Room: 

PARALLEL ARCHITECTURE AND ALGORITHMS 
Chairperson: C. W. Wang -Beijing Institute of System Engineering, 
CHINA 

Optimal Number of Processors for Finding the Maximum Value on 
Multiprocessor Systems,- S. Horiguchi, Y. Shigei -Tohoku 
University, JAPAN 

Fast Data Searching and Distribution on the Butterfly Network; 

W. Lin, T. Sheu -Pennsylvania State University, USA 
Reliable Garbage Collection in Distributed Object-Oriented 
Systems; A. Gupta, W. K. Fuchs -University of Illinois at Urbana- 
Champaign, USA 

Session B-5T, Buckingham Room: 

Panel Session 

COHERENT ANALYSIS AND INTELLIGENT MACHINE 
TRANSLATION FROM JAPANESE TO ENGLISH 
Chairperson: [. Aoe -University of Tokushima, JAPAN 
Panelists: Y. S. Alan -University of Texas at Austin, USA; R. Cohen 
University of Waterloo, CANADA; M. Fujikawa -University of 
Tokushima, JAPAN; T. Sato -Takuma National College of 
Technology, JAPAN 

3:30-4:00 p.m. BREAK 

4:00-5:30 p.m. FOUR PARALLEL SESSIONS 


Session G-6T, Gold Room: 

REQUIREMENTS SPECIFICATIONS 
Chairperson: S. C. Chang -GTE, Inc., USA 
Correctness for Beginners; M. Naftalin -University of Stirling, 
Scotland, UK 

Editing Model Based on the Object-Oriented Approach; T. Watanabe, 
Y. Yoshida, T. Fukumura -Nagoya University, JAPAN 
Another Approach to System Decomposition: Requirements 
Clustering; P. Hsia, A. T. Yaung -University of Texas at Arlington, 
USA 

An Approach to Software Requirement Specification; S. S. Yau - 
University of Florida, C. Liu -Northwestern University, USA 

Session W-6T, Windsor Room: 

LIFE CYCLE SUPPORT TOOLS 2 
Chairperson: A. Davis -BTG, Inc., USA 
Integrating Three Tool-Based Approaches to Software Engineering 
Method; R. A. Nicholl -University of Western Ontario, CANADA 
Automated Testcase Generation for Data Abstraction; P. Jalote, 

M. G. Caballero - University of Maryland, USA 
Scheduler 1 *2*3: An Interactive Schedulability Analyzer for 
Real-Time Systems; H. Tokuda, M. Kotera -Carnegie Mellon 
University, USA 

Finding Program Slices for Recursive Procedures: An Attribute 
Method; J. C. Hwang, M. W. Du, C. R. Chou -National Chiao-Tung 
University, Taiwan, CHINA 

Session F-6T, Florentine Room: 

ADVANCED DATABASES 

Chairperson: H. Lee -Bell Communication Research, USA 
An Algebraic Technique for Deductive Database System; Y. Jiang - 
University of Essex, UK 

A Probabilistic Study on a Transactions Waits and Deadlocks from 
Viewpoints of a Locking Request; Y. F. Huang, Y. H. Chin -National 
Tsing Hua University, Taiwan, CHINA 

A Logic for Handling Time in Tempora Data Bases; M. A. Bassiouni 
University of Central Florida, USA 

A Fully-Distributed Approach to Concurrency Control in Replicated 
Database Systems; M. Singhal -Ohio State University, USA 

Session B-6T, Buckingham Room: 

ALGORITHMS AND LOGICS 

Chairperson: A. Pau -Anthony Pau and Associates, Hong Kong 
An Efficient Digital Search Algorithm by Using a Double-Array 
Structure; J. Aoe -University of Tokushima, T. Sato -Takuma 
National College of Technology, JAPAN 

Extension on a Performance Evaluation Technique for Decision-Free 
Petri Nets; C. V. Ramamoorthy, Y. Yaw, S. Satoh -University of 
California at Berkeley, W. T. Tsai -University of Minnesota, USA 
Weighted Fuzzy Logic and its Applications; H. Xingui -Beijing 
Institute of System Engineering, CHINA 

Nonrecursive Algorithms for Reconstructing a Binary Tree from its 
Transversals,- G. H. Chen, M. S. Yu, L. T. Liu National Taiwan 
University, Taiwan, CHINA 


Friday, October 7, 1988 


9:00-10:00 a.m. Keynote: (G-PF) Gold Room 
SOFTWARE ENGINEERING: RETROSPECT AND PROSPECT: 
Harlan D. Mills -University of Florida and Information Systems 
Institute, USA 

10:00-10:15 a.m. BREAK 

10:15 a.m.-11:45 a. m. FOUR PARALLEL SESSIONS 

Session G-7F. Gold Room: 

Mini-Review 

Chairperson: G. D. Kraft -Illinois Institute of Technology, USA 


SOFTWARE MAINTENANCE. W. Osborne -National Bureau of 
Standards, USA 

Session W-7F, Windsor Room: 

Panel Session 

SOFTWARE DEVELOPMENT ENVIRONMENT STATE-OF-ART 
Chairperson: H. Weber -University of Dortmund, FRG 

Session F-7F, Florentine Room: 

Mini Review 

Chairperson: K. H. Kim -University of California at Irvine, USA 









OBJECT-ORIENTED DBMS. A. Rudmik -GTE Communications, USA 

Session B-7F, Buckingham Room: 

Panel Session 

EXPERT SYSTEM AND SOFTWARE ENGINEERING 
Chairperson: J. J. Tsai 

Panelists: M, Tanik -Southern Methodist University, USA; W. Tsai 
-University of Minnesota, USA; M. Harandi -University of Illinois 
at Chicago, USA; W. Scacchi -University of Southern 
California, USA; D. Y. Yun -Southern Methodist University, USA 

11:45 a.m.-12:00 p.m. BREAK 

12:00-1:30 p.m. FOUR PARALLEL SESSIONS 

Session G-8F, Gold Room: 

SYSTEM PERFORMANCE ANALYSIS 
Chairperson: T. Nakamura -Tohoku University, JAPAN 
Design and Implementation of the High Performance Integrated 
Voice/Data Token Ring Protocol; J. Y. Lee -POSTECH, KOREA, 

D. W. Jacobson -Iowa State University, USA 
A Simulation Approach for Network Operations Performance 
Studies; A. L. Chen, E. J. Cameron, G. F. Shuttleworth, E. C. 

Anderson -Bell Communications Research, Inc., USA 
A Technique to Derive the Detailed Time Costs of Parallel 
Computations; R. A. Ammar, B. Qin -University of Connecticut, USA 

Session W-8F, Windsor Room: 

SOFTWARE REUSE 

Chairperson: K. Reed -Royal Melbourne Institute of Technology, 
AUSTRALIA 


Building and Managing Software Libraries; G. Jones, R, Pricto-Diaz 
-GTE Laboratories, USA 

A Model for Development of Customizable Applications; 

M. Atchan, R. Bell -Honeywell, Inc. USA 

Session F-8F, Florentine Room: 

DATABASE TOOLS AND ANALYSIS 
Chairperson: J. S. Ke -Institute of Information Industry, 

Taiwan, CHINA 

Database Design Tool Generation via Software Reusability; 

S. Hong, F. Maryanski -University of Connecticut, USA 
An Evaluation of Software Structure Metrics; B. A. Kichenham - 
City University-London,UK 

A Database Query Language for Visual Interfaces; K. Kawagoe - 
NEC Corporation, JAPAN 

Session B-8F, Buckingham Room: 

CONCURRENT SYSTEMS 

Chairperson: R. Iyer -University of Illinois at Urbana, USA 
A Synthesis Approach for Designing Concurrent Systems; C. V. 
Ramamoorthy, Y. Yaw -University of California at Berkeley, W. T. 
Tsai -University of Minnesota, USA 

Protocol Synthesis in a State-Transition Model; P. M. Chu, M. T. 
Liu -Ohio State University, USA 

Asynchronous Recovery Protocols for Distributed Systems; K. W. 
Hwang, W. T. Tsai -University of Minnesota, USA 


HOTEL REGISTRATION FORM 


Complete and mail your hotel reservation form to: THE CONGRESS 

HOTEL, 520 South Michigan Avenue, Chicago, 1L 60605 U.S.A., (312) 
427-.I81K). To confirm your room reservation, the Congress must receive 
this coupon by SEPTEMBER 12, 1988. Rooms will be held until 6:00 
p.m. on the day of arrival unless otherwise confirmed by the hotel. 
Please indicate the type of room you desire: 

□ Single at $60 . C3SingIeat$64 

fcl Double/TVrin at $70 □ Double at $74 

Arrival Date___A.M. P.M. 

Departure Date-A.M_P.M. 


MAJOR CREDIT CARDS ACCEPTED 
(Please Prim Name As It Appears on Card) 


•equired for credit cards! 



; Duplicate this, form if i 
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Editor: Sallie Sheppard, Office of Associate Provost for Honors Program and Undergraduate Studies, Texas A&M University, College Station, TX 77843; (409) 845-3210 


TAB, 8 technical committees to conduct inaugural satellite symposium 


Compusat 88, an ambitious first-ever 
interdisciplinary satellite symposium 
cosponsored by the Computer Society’s 
Technical Activities Board and eight 
society technical committees, is sched¬ 
uled for telecast Tuesday, October 4. 

Among other features, the live 
videoconference will include talks by 
such industrial and academic leaders as 
Gordon Bell, father of the VAX; VLSI 
pioneers Lynn Conway and Carver 
Mead; and John Sculley, chief executive 
officer of Apple Computer. 

Paul Hazan of the Johns Hopkins 
University Applied Physics Laboratory 
is chairing Compusat, with Nicolas 
Vogel of Singer the program adminis¬ 
trator, and Kenneth R. Anderson of 
Siemens and Laurel Kaleda of IBM the 
TAB Steering Committee chairs. 
Anderson is president-elect of the soci¬ 
ety, and Kaleda is vice president for 
technical activities. 

The five-hour telecast is being tar¬ 
geted toward the professional who is— 
or expects to be—involved in the use or 
design of computer-based systems, and 
should also interest student engineers, 
scientists, and technologists seeking to 
broaden their perspectives on interdis¬ 
ciplinary applications. 

The theme will be “The Interdiscipli¬ 
nary World of Computing.” The inter¬ 
active satellite conference will provide a 
unique interdisciplinary experience 
designed to bridge individual specialties 
and other critical aspects of the comput¬ 
ing field. 

The conference will feature one-way 
video and two-way audio, and will run 
from 11:30 a.m. to 4:30 p.m. Eastern 
Time. 

Varied program. The program will 
feature presentations on trends in 
prominent computer technologies, a 
comprehensive update of key develop¬ 


ments, plus interviews, minitutorials, 
and panel discussions with audience 
participation. 

Compusat will be the first satellite 
symposium to include presenters from a 
wide range of important centers of com¬ 
puter research and development. 

Over 35 companies, educational insti¬ 
tutes, and governmental agencies will 
provide demonstrations, capsule 
tutorials, technical commentaries, and 
viewpoints. 

Computer Society TAB technical 
committees collaborating on develop¬ 
ment of the telecast are the TCs on 
Design Automation, Office Automa¬ 
tion, Pattern Analysis and Machine 
Intelligence, Personal Computing, 
Robotics, Software Engineering, Test 
Technology, and Very Large Scale Inte¬ 
gration. 

Each TC will make a presentation on 
current-technology trends and future 
directions in its technical specialty area 
and will work cooperatively with the 
others to tie the areas together. 

Compusat will deal with many of the 
key elements in computer design and 
applications. Beginning with trends in 
the design of underlying VLSI compo¬ 
nents found in every modern electronics 
application, the program will cover 
design automation and test technology, 
both of which involve methods widely 
applicable throughout computer design 
itself and in many applications of com¬ 
puters. 

Next, the focus will shift to software 
engineering for an appreciation of the 
common problems and trade-offs faced 
in hardware and software design and 
the advanced tools and techniques 
brought by each community. The pro¬ 
gram segments on personal computing 
and office automation will deal with the 
latest systems now of interest to most 
Americans. The final segment will 


probe computer vision, machine intelli¬ 
gence, and robotics, some of the most 
advanced and often speculative applica¬ 
tion areas where digital machines are 
increasingly capable of performing 
tasks less specifically defined than in the 
past. 

Viewers will be able to express their 
ideas, concerns, and recommendations 
and to pose questions, which will be 
relayed to a panel of experts for 
response and discussion. Audience 
input will also provide the basis for 
planning future events and initiatives. 

Satellite network. The symposium 
will be aired for viewing at several hun¬ 
dred sites via satellite through an inter¬ 
active network in Continental North 
America and the Caribbean using both 
C Band and Ku Band transmission. 

Over 10,000 persons are expected to 
participate at local IEEE sections and 
chapters, and at campus, industrial and 
governmental locations. 

Compusat is being developed using 
the support and facilities of the IEEE 
satellite network. 

Computer Society chapters and sec¬ 
tions, plus companies, schools and 
other organizations, may obtain details 
on how to sign up as network sites at 
their locations by contacting the IEEE 
Service Center, Educational Activities 
Department, 445 Hoes Lane, PO Box 
1331, Piscataway, NJ 08855-1331, 
phone (201) 562-5494. 

Information is also available to 
individuals regarding locations in their 
areas where they may view Compusat 
without formally establishing a telecast 
reception site of their own. To obtain a 
list of such sites, call or write to Robert 
Kahrmann at the IEEE Service Center 
address and/or phone number listed 
above. 
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Addressing Board of Governors, Parrish reports 
hikes in society memberships, subscriptions 


Sal lie Sheppard 

President Edward A. Parrish, Jr., 
reported increases in both memberships 
and subscriptions when he opened the 
Computer Society Board of Governors 
meeting in Anaheim June 17. The ses¬ 
sion was held in conjunction with the 
25th Design Automation Conference. 

In his introductory message, Parrish 
noted the overall health of the society 
and said that membership is up approxi¬ 
mately 13 percent over last year while 
subscriptions to the society’s magazines 
and transactions are also up. 

Extensive effort has been focused on 
establishing the new society office in 
Tokyo. Space has been leased in Tokyo, 
with office operation scheduled to begin 
shortly. Asian Operations Manager 
Kyoko Mikami was introduced to the 
board. 

The Brussels office that opened in 
1985 has been very successful in meeting 
the needs of society members in 


Europe. It is hoped the Tokyo office 
will likewise enhance service in the 
Pacific Region. 

Parrish announced that the society is 
seeking to foster intersociety coopera¬ 
tion in Europe. At its spring meetings, 
held in April in Brussels during Comp- 
Euro, the society’s Executive Commit¬ 
tee hosted a reception for the presidents 
of the European national societies. Par¬ 
rish indicated follow-up activities are 
underway to further develop relation¬ 
ships with the European groups. 

In other action, the board approved a 
$15 member fee for 1989 (the third year 
without an increase), increased editorial 
pages for society transactions for 1989, 
and voted second approval to bylaws 
amendments for creating a Computer 
Society Press Activities Board and for 
presenting opposing view position state¬ 
ments (see pp. 78-79 of the May issue of 
Computer). 


Increases in page budgets 
of transactions approved 


Sallie Sheppard 

At its June 17 meeting, the Board 
of Governors of the Computer Soci¬ 
ety approved an increase of 850 
pages in 1989 page budgets for three 
of the society’s transactions. 

IEEE Transactions on Pattern Anal¬ 
ysis and Machine Intelligence will be 
expanded from bimonthly to monthly 
publication, with an increase of 450 
editorial pages. Steve Tanimoto, 
editor-in-chief, said expansion of the 
journal will allow continued publica¬ 
tion of pattern recognition papers as 
well as increased coverage of related 
artificial intelligence topics. Sub¬ 
scription rates will be increased by 
$5. 

IEEE Transactions on Software 
Engineering and IEEE Transactions 
on Computers will be expanded by 
200 pages each in 1989, with $2-per- 
year increases in subscription rates 
for members. 

In addition, both publications got 
approval for 150-page increases this 
year to permit reduction in backlogs 
of accepted papers. Victor Basili, 
editor-in-chief of IEEE Transactions 
on Software Engineering, noted that 
the Technical Committee on Soft¬ 
ware Engineering has contributed 


$15,000 toward offsetting the cost of 
the increased page counts. 

In requesting the increases, James 
Aylor, vice president for publications, 
noted that increases in subscribers 
as well as numbers of contributed 
papers is evidence of the popularity 
of the transactions. 

The approved increases in pages 
will allow the society to enhance its 
service to members and the techni¬ 
cal community. 

The three transactions, along with 
the new IEEE Transactions on Knowl¬ 
edge and Data Engineering slated to 
begin quarterly publication in 1989, 
provide society members a valuable 
mechanism for monitoring the evolv¬ 
ing state of the art of computer fields. 

In a separate action, the board 
recommended reappointment of five 
editors-in-chief for second two-year 
terms. They are Bruce Shriver of 
Computer, John Staudhammer of 
IEEE Computer Graphics and Appli¬ 
cations, Ted Lewis of IEEE Software, 
Ming T. Liu of IEEE Transactions on 
Computers, and Tanimoto of IEEE 
Transactions on Pattern Analysis and 
Machine Intelligence. 


Computer Society’s 
six magazine managing 
editors cited for 
outstanding service 

The managing editors of the Com¬ 
puter Society’s six magazines have been 
awarded certificates for outstanding 
performance. The presentations took 
place during the Magazine Planning 
Workshop June 13 in the society’s Pub¬ 
lications Office at Los Alamitos, 
California. 

Marilyn Potes of Computer, Marie 
English of IEEE Micro, and Margaret 
Neal of IEEE Computer Graphics & 
Applications each received a Meritori¬ 
ous Service Certificate, while Henry 
Ayling of IEEE Expert, Angela Burgess 
of IEEE Software, and Nancy Summers 
of IEEE Design & Test of Computers 
each received a Certificate of 
Appreciation. 

James H. Aylor, publications vice 
president and chair of the Publications 
Board, presented the framed citations 
bearing the signature of society Presi¬ 
dent Edward A. Parrish, Jr. Sallie 
Sheppard, Magazine Advisory Commit¬ 
tee chair, was in charge of the 
workshop. 

Potes joined the society as assistant 
editor of Computer 14 years ago and 
has served in managing editorships the 
last 7 / years. She first became ME of 
the monthly magazine in December 
1980 and later served as the first manag¬ 
ing editor of both IEEE Software and 
D&T for 2/ years before reassuming her 
Computer post in September 1986. 

Potes received a BA degree in jour¬ 
nalism magna cum laude at the Univer¬ 
sity of Washington in Seattle and, prior 
to joining the society staff in April 
1974, was an advertising copywriter and 
an elementary school teacher. She is a 
member of Women in Communications 
and a senior member of the Society for 
Technical Communication. 

English has been on the CS staff since 
October 1983, first as assistant editor of 
CG&A. She was appointed managing 
editor of bimonthly IEEE Micro in Sep¬ 
tember 1985. 

Previously, English served five years 
as a technical writer for sales proposals 
with the Occidental Engineering Co., 
Irvine, California. She has a BA in his¬ 
tory from California State University at 
Fullerton. 

Neal joined the staff as managing edi¬ 
tor of the bimonthly IEEE Computer 
Graphics & Applications in September 
1984 after IV/. years as an editorial vice 
president with a division of Prentice- 
Hall in Waterford, Connecticut. 
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Neal is an alumna of the University 
of Wisconsin and Stephens College in 
Missouri and a member of the Com¬ 
puter Press Association and the Inter¬ 
national Association of Business 
Communicators. 

Ayling was named managing editor 
of IEEE Expert in June 1986 after hav¬ 
ing joined the society staff in September 
1985 and serving as assistant editor of 
that quarterly publication as well as 
D&T and IEEE Software. 

Previously, Ayling served in adminis¬ 
tration and management with four 
international airline companies and was 
an instructor at Long Beach City Col¬ 
lege. He received a BA in English at 
Grinnell College in Iowa and an MA in 


English and rhetoric at California State 
University at Dominguez Hills. He is an 
editorial advisor of CanAm Program¬ 
ming, Inc. 

Burgess began her Computer Society 
tenure as assistant editor of both IEEE 
Software and D&T in April 1985, and 
later served as assistant editor of CG&A 
before accepting the post of managing 
editor of the bimonthly IEEE Software 
in July 1986. 

Before joining the CS staff, Burgess 
was employed by Times Mirror, Los 
Angeles. She was awarded a BS in jour¬ 
nalism and Soviet studies by Iowa State 
University. 

Summers became managing editor of 
the bimonthly IEEE Design & Test of 


Technical Committee on Operating Systems active 

Joseph Boykin, chair. Technical Committee on Operating Systems 


The Computer Society recognizes the 
importance of operating systems in 
computing today. The Technical Com¬ 
mittee on Operating Systems is actively 
working in a number of research areas. 

Our premier Workshop on Worksta¬ 
tion Operating Systems, held in Novem¬ 
ber 1987, examined research on the 
future direction of operating systems in 
this fast-growing area. Another work¬ 
shop is being planned for 1989. Those 
interested in this workshop should con¬ 
tact me at the address shown below. 

Standards is another active TCOS 
area. Our subcommittee on operating 
system standards, led by Jim Isaak of 
Digital Equipment, has been working 
on the IEEE P1003 Posix effort for 
several years. 

Posix, Portable Operating System 


Interface for Computer Environments, 
has been a trial-use standard for almost 
two years and has received an affirma¬ 
tive ballot as a full-use standard. A 
final ballot is expected shortly and is 
expected to be approved. 

Basic software element. Operating 
systems have been the fundamental 
piece of software on every computer 
system since the origin of the digital 
computer. Initially viewed as no more 
than a means to isolate the user from 
managing physical I/O devices, the 
operating system has changed radically 
over the years. 

Modern operating systems provide a 
multi-user multiprocess timesharing 
environment. Many of these systems are 
networked together to provide capabili¬ 
ties from simple file transfer to heter- 


Students win prizes in Computer Society’s 
International Science and Engineering Fair 


Nabeel Shirazi of Beaver Creek 
(Ohio) High School has taken first- 
place honors in this year’s Computer 
Science International Science and 
Engineering Fair at Knoxville, Tenn. 

Shirazi was awarded $250 for his 
project entitled “Performance Mea¬ 
sures of Evaluating Reconfigurable 
Multiprocessing Architectures.” 

The second-place prize of $100 went 
to Ali R. Alaie of William Cullen 
Bryant High School in Long Island, 
N.Y., for a project called “The 
Diagonal Network.” 


Third-place honors and $75 were 
presented to Paul L. Kollmorgan of 
Luther High North in Mt. Clemens, 
Mich., for his project “Development of 
Compression Techniques for the Effi¬ 
cient Storage of Data.” 

Each student also received a certifi¬ 
cate, a plaque, and a one-year student 
membership in the society. 

Jon McDearman, Homer Powell, and 
S.B. Khleif of Tennessee Technological 
University in Cookeville, Tenn., served 
as judges in the Computer Society- 
sponsored event, held May 11-12. 


Computers in August 1986, four years 
after joining the society staff as assis¬ 
tant editor of Computer. She has 
worked as assistant editor of all six of 
the society’s magazines, including serv¬ 
ing as issue editor of the award-winning 
centennial edition of Computer in 
October 1984. 

She graduated cum laude from James 
Madison University in Virginia with a 
BA in English, emphasizing technical 
communication in her studies. Prior to 
joining the CS staff, Summers was a 
technical editor for government con¬ 
tractors with such clients as the US Air 
Force, the US Environmental Protec¬ 
tion Agency, and the Defense Advanced 
Research Projects Agency. 


in varied areas 


ogeneous distributed processing 
capabilities. 

Some have speculated that the oper¬ 
ating system will cease to exist in the 
next generation of graphic worksta¬ 
tions. While this is unlikely, it is appar¬ 
ent that operating systems must take on 
new and different roles. 

For example, Unix on a Macintosh 
and a Cray may be able to run the same 
utilities, but will have drastically differ¬ 
ent user interfaces. Distributed process¬ 
ing environments such as Apollo’s NCA 
or Sun’s NFS required additional facili¬ 
ties to work in a networked environ¬ 
ment of heterogeneous systems. Such 
facilities included the ability to pass 
data between different machine 
architectures. 

Newly emerging architectures, such 
as shared memory multiprocessors, 
require operating system changes to 
make all the computing power of the 
system available to the user. With all 
these new technologies, it appears oper¬ 
ating systems are here to stay. 

Participation invited. TCOS invites 
those interested in operating system 
design and development to join our TC 
and participate in our workshops and 
standards activities. Our newsletter is 
now published quarterly and contains 
technical articles, information on the 
status of our standards activities, 
announcements of conferences in the 
field, and general interest items. 

For additional information, contact 
Joseph Boykin, Encore Computer, 257 
Cedar Hill St., Marlborough, MA 
01752-3004, phone (617) 460-0500 ext. 
2644. 
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Contributions to Update are welcome. Send news of industrial or university research and of public policy or professional issues to Update Editor, 10662 Los Vaqueros Circle, 
Los Alamitos, CA 90720, or to Bruce Shriver, Editor-in-Chief, Dept, of Decision Sciences, University of Hawaii, 2404 Maile Way, Honolulu, HI 96822. 


IBM veteran Morton Astrahan 
leaves legacy of accomplishment 


IBM veteran Morton Michael Astra¬ 
han died June 2 in a Los Gatos, 
California, convalescent home after a 
prolonged fight with rheumatoid spon¬ 
dylitis and Parkinson’s disease. He was 
63. 

Born in Chicago, Astrahan was 
instrumental in the development of the 
I/O interrupt. He also organized and 
was the first chairman of the IRE 
Professional Group on Electronic Com¬ 
puters, forerunner to the Computer 
Society. 

Astrahan received his PhD in Electri¬ 
cal Engineering from Northwestern 
University and joined IBM as a research 
technician in 1949. One year later he 
was involved in the specification and 
logic design of IBM’s 701 computing 
system, the company’s first commercial 
stored-program binary computer. 

By 1952, Astrahan had been given 
complete responsibility for I/O system 
development and prototype testing for 
the AN/FSQ7 computer at IBM’s 
Poughkeepsie facility. The computer— 
developed for the SAGE air-defense 
system and in use through 1983—was 
the world’s first large-scale timesharing 
system and the first to use active/stand¬ 
by duplexing. He contributed the con¬ 
cepts of index registers for parallel com¬ 
puters, associative memory (retrieval of 
data by content), and the I/O interrupt, 
eventually leading to three patents. 

He worked in San Jose from 1956 to 
1962, where his work included directing 
research in multiterminal communica¬ 
tions systems and multiplexing systems 
(leading to the first typewriter-style ter¬ 
minal and one of the first text editors), 
and planning and engineering a 
timeshared business data processing sys¬ 
tem, which resulted in one of the first 
business utilities packages. 

After two years at IBM World Trade 
in Paris, Astrahan returned to Los 
Gatos, where he worked on the defini¬ 
tion and early development of a 
computer-aided instruction system that 
was installed with the cooperation of 
Stanford University. 

In 1969 Astrahan took a sabbatical at 
the Stanford Artificial Intelligence Lab 


to work with Raj Reddy and Art 
Samuels on speech recognition. 

He returned to San Jose in 1970, con¬ 
ducting research into database systems, 
including work on the Data Indepen¬ 
dent Accessing Model, development of 
SQL, System R, high-performance 
optimization, and highly available 
systems. 

Astrahan retired from IBM on Janu¬ 
ary 1, 1985. 

In addition to his position as chair of 
IRE, Astrahan was a member of the 
Joint Computer Conference Committee 
from 1952 to 1986, chairman of the 
National JCCC from 1956 to 1958, and 
chairman of the JCCC of AFIPS from 
1966 to 1969. 

He was named an IEEE Fellow in 
1969, and he received the AFIPS Distin¬ 
guished Service Award in 1975, the 
Northwestern University Merit Award 
in 1980, the IEEE Centennial Award in 
1984, and an Emeritus of the National 
Computer Conference Committee in 
1986. 

Memorial donations may be made to: 


Person 


tclose 


Wider software availability is helping 
/ personal computers push their way far- ^ 
ther into the scientific and engineering 
y market that was once dominated by 
necial-Duroose workstations. 

A newly released 
Sullivan titled “Scientific and Engineer¬ 
ing Personal Computers and Related 
Software Market in the US” shows that 
1,204,600 US-made scientific/engineer¬ 
ing personal computers were in use 
worldwide at the end of 1987. 

Unit sales in that area are expected to 
rise at a compound annual rate of 21 
percent, making the current $1.3 billion 
market a $3.2 billion market in 1992, in 
spite of falling hardware prices. 

The report found that the market for 
add-ons, which are vital for using PCs 
as scientific/engineering tools, is 
expanding at an annual rate of 32.7 per- 



Morton Michael Astrahan 


The Morton M. Astrahan Research Fund, 
USC Kenneth Norris Hospital, Dept, of 
Radiation Oncology-Hyperthermia, 1441 
Eastlake Ave., Los Angeles, CA 90033; 
Attn: Z. Petrovich. 


in on workstations 

cent in dollars. 

The report stated, however, that soft¬ 
ware is the driving force behind the 
growth of PCs in this market. With 
more than 100 vendors targeting the 
scientific/engineering market, unit sales 
are expected to expand at an annual 
rate of 39 percent over the next five 
years, creating a $1.2 billion market by 
1992. 

Frost & Sullivan noted that some 
drawbacks have held back the scien¬ 
tific/engineering PC market, such as 
the delayed release of Microsoft’s OS/2 
and the resulting lack of application 
software to take advantage of 32-bit 
processors. 

For more information on the $2,000 
report, contact Customer Service, Frost 
& Sullivan, Inc., 106 Fulton St., New 
York 10038. 
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University of Michigan students clinch chip 
design contest 


University of Michigan engineering 
students James W. Dolter and 
Parameswaran Ramanathan took first 
prize in the sixth annual Student VLSI 
Design Contest for the most innovative 
chip design. 

Eight industry professionals acted as 
judges for the competition, looking for 
sound engineering principles and clear 
descriptions of the work, and assessing 
how easily the chip could be produced 
and tested. 

A total of $12,000 cash and five cal- 


McDonnell Douglas has reported suc¬ 
cessfully demonstrating the world’s 
fastest 32-bit reduced-instruction-set 
computer processor. The single chip 
microprocessor, dubbed the MD-484, 
has been clocked at almost 60 mega¬ 
hertz and produces an output every 17 
nanoseconds. 

Developed under a Defense Advanced 
Research Projects Agency contract for 
use in Strategic Defense Initiative 
studies, the chip was produced at the 
gallium arsenide microelectronics 


NASA develops air-flow 

NASA has developed a new computer 
model that reportedly mirrors complex 
patterns of air flow and might lead to 
significant advances in jet-engine design. 

The model, developed by Man 
Mohan Rai of NASA’s Ames Research 
Center in Mountain View, California, is 
expected to be ready for commercial 
applications within three to five years. 

It analyzes rotor-stator air flows and 
provides precise analysis of interior 
changes in pressure, temperature, and 
velocity. 

Unsteady air flow caused by the rela¬ 
tive motion of some components, or by 
gusts of wind or other changes of pres¬ 
sure, creates fluctuating pressures on 
engine parts, resulting in thermal and 
mechanical fatigue and drastically 
reducing the lifetime of parts. The 
NASA model can help designers mini- 


culators were awarded to the top 10 
entries. The first prize winners receievd 
$2,857. 

University of Michigan students cap¬ 
tured five of the top six awards, with 
the remainder of the top 10 prizes going 
to students from the University of Utah 
and Utah State University. Industrial 
sponsors included Seattle Silicon, Men¬ 
tor Graphics, VLSI Technology, Ford, 
National Semiconductor, General 
Motors, AT&T, ECAD, and Hewlett- 
Packard. 


laboratory at McDonnell Douglas 
Astronautics. Gallium arsenide is a 
semiconductor material that reportedly 
provides faster speed than silicon semi¬ 
conductor integrated circuits. 

The chip design is based on the RISC 
architecture originated at Stanford Uni¬ 
versity in the early 1980s. The MD-484 
chip consists of 21,606 transistors, with 
17 general-purpose registers and a full 
32-bit arithmetic logic unit. In addition, 
it provides a barrel shifter for special¬ 
ized computer operations. 


mize such stresses by predicting where 
they will occur. Smaller, lighter, and 
more-efficient engines could also result 
from use of the model. 

The model can be applied to a wide 
variety of jet engines, and adaptation 
may allow it to be used with other rotat¬ 
ing machinery, such as prop fans and 
helicopter rotors. 

The simulation currently involves 22 
trillion computations, requiring 100 
hours on a Cray-2 supercomputer. 
Within a year, researchers expect to 
reduce the runtime to 20 hours, and to 
between one and 10 hours in three to 
five years, depending on potential 
refinement of the new model and 
increases in supercomputer speed. 

Commercial use of the model could 
replace the current costly practice of 
building and testing prototype engines. 


Engineers support 
protection for ‘whistle 
blowers,’ higher 
standards for industry 

Engineers involved in activities 
affecting the public’s health or safety 
should be licensed, and stronger laws 
should protect professionals who air 
concerns about safety deficiencies, a 
new survey indicates. 

These attitudes are revealed in the 
recently released 1988 IEEE US Mem¬ 
ber Opinion Survey. The survey ques¬ 
tionnaire was mailed early in the year to 
8,000 randomly selected US IEEE mem¬ 
bers above student grade. A consultant 
tabulated some 3,540 responses, 
representing a 44.3 percent response rate. 

Some 78 percent of the respondents 
called for the licensing of engineers 
involved in health- or safety-related 
activities, and 44 percent recommended 
certification within specialties of electri¬ 
cal engineering or related fields. 

The surevy also shows that a majority . 
of IEEE members believe that stronger 
laws should protect professionals who 
publicly air concerns about “substan¬ 
tiated claims of major safety deficien¬ 
cies.” An even larger majority said that 
the JEEE should continue to intervene 
on behalf of members who are fired or 
otherwise punished for “whistle blowing.” 

On the subject of career preparation, 
the respondents said that an exam test¬ 
ing for overall knowledge of 
mathematics and natural sciences 
should be recommended, if not 
required, for a bachelor’s degree in elec¬ 
trical engineering. 

In addition, 70 percent agreed that 
evidence of continuing professional 
competence should be at least a recom¬ 
mendation for remaining an engineer. 

Other subjects covered in the 
112-page report include the influence of 
technology on the public welfare, per¬ 
sonal computers in the workplace, and 
IEEE services and decision-making. 

The 1988 IEEE US Member Opinion 
Survey can be purchased by IEEE mem¬ 
bers for $5 and by nonmembers for 
$7.50. Contact Publication Sales, IEEE 
Service Center, 445 Hoes Lane, PO Box 
1331, Piscataway, NJ 08854-4150; 
phone (201)981-0060. 

A free companion publication, Com¬ 
ments to the USAB 1988 Member Opin¬ 
ion Survey, is available through IEEE 
USAB, 1111 19th St. NW, Suite 608, 
Washington, DC 20036-3690; phone 
(202) 785-0017; Attn: William R. 
Anderson. 


McDonnell Douglas demonstrates RISC 
processor 


model 
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Operating environments for the 80386 

Richard Eckhouse, New Product Reviews editor 


Given the power of the Intel 80386, it 
comes as no surprise that this micro¬ 
processor in a PC can perform on a par 
with much larger minicomputer sys¬ 
tems. In what follows, I take a look at a 
number of alternative 386 operating 
environments for the user wishing to get 
more out of his or her machine. These 


multitasking (and multiuser) systems 
take advantage of the virtual 8086 mode 
of the 386. In most cases, these operat¬ 
ing environments are capable of run¬ 
ning concurrently almost all of the 
traditional applications, including word 
processors, communication packages, 
spreadsheets, and databases, not to 


mention the vast array of utility soft¬ 
ware that requires special DOS features 
or directly controls hardware. 

My examination of several operating 
environments includes Windows/386 
from Microsoft (reviewed with the 
assistance of Michael Dideu), PC- 
MOS/386 from The Software Link, and 


Table 1. Features summary. 


Feature 

Windows 386 

PC-MOS/386 

VM/386 

DV/QEMM 

Multitasking environment 

Yes 

Yes 

Yes 

Yes 

Multiuser environment 

No 

Yes 

No 

No 

Uses a windowing environment 

Yes 

No 

No 

Yes 

Graphics oriented 

Yes 

No 

No 

No 

Needs CGA or EGA capability 

Yes 

No 

No 

No 

Creates virtual machines 

Yes 

Yes 

Yes 

No 

Uses demand paging 

Fully protected virtual machines or 

No 

No 

No 

No 

windows 

Partial 

Yes 

Yes 

No 

Supports expanded memory 

Yes 

Yes 

Yes 

Yes 

Supports extended memory 

Each task has config.sys file and 

No 

No 

Yes 

No 

autoexec.bat file 

Runs different DOS versions 

No 

No 

Yes 

No 

concurrently 

No 

No 

Yes 

No 

Needs application descriptors 

Can reboot virtual machine or 

Yes 

No 

No 

Yes 

window 

No 

No 

Yes 

No 

Can run applications that write 
directly to video 

Dynamically updates each virtual 

Yes 

Yes 

Yes 

Yes 

machine or window 

Can set amount of memory per 

No 

Partial 

Yes 

No 

application 

Yes 

Yes 

Yes 

Yes 

Uses hot-key 

Yes 

Yes 

Yes 

Yes 

Fast switching between applications 

Yes 

No 

No 

Yes 

Mouse support in each virtual 

Exclusive 




machine or window 

mode only 

Yes 

Yes 

Yes 

Supports RAM-resident programs 

Yes 

Yes 

Yes 

No 

Cut/paste clipboard 

Yes 

No 

No 

Yes 

Must change hard disk boot 

No 

Yes 

No 

No 

Runs on Intel processor(s) 

80386 

8086, 

80386 

8086, 



80286, 


80286, 



80386 
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Microsoft’s Windows 


VM/386 from IGC. Each offers a set of 
common features and a set of unique 
features not found in the other systems. 
This variety offers an excellent choice 
for the user with special requirements. 

I’ve put together a features summary 
for the different operating environ¬ 
ments tested for this column (see the 
accompanying table). While I think it is 
100-percent accurate, it is based on my 
experience. I apologize in advance for 
any disagreements that might arise. 

Even so, I think my summary will prove 
useful for readers wishing to differenti¬ 
ate between the products. 


Wonderful world of Windows 

Many users, ourselves included, have 
hesitated to use Microsoft Windows. 

Yet, as an extension to DOS that would 
allow us to open multiple windows and 
hence multiple applications, Windows 
looked like an excellent addition to the 
limited command-language interface 
that PC- and MS-DOS offer. After all, 
with a couple of keystrokes, or by 
pointing and clicking on a mouse, we 
could rapidly switch between different 
applications. By not having to exit from 
one program to switch to another, we 
could move from application to appli¬ 
cation without losing the context. And 
the built-in clipboard allowed us to 
transfer text and graphics between 
applications. 

The only catch was some serious limi¬ 
tations in the original version. Windows 
was slow, did not support more than 
640 Kbytes of conventional memory, 
used tiled (that is, nonoverlapping) win¬ 
dows, and did not work well with appli¬ 
cations not written specifically for the 
Windows environment. However, the 
introduction of the latest versions, Win¬ 
dows 2.03 and Windows/386, has 
changed all of that. These products run 
considerably faster than their earlier 
versions, can use both expanded and 
extended memory, support overlapping 
windows, and, most importantly, are a 
pleasure to use. 

The products. The two latest versions 
of Windows differ considerably. Win¬ 
dows 2.03 runs on any member of the 
IBM PC family, the PS/2 family, and 
many compatibles. Minimal require¬ 
ments are DOS 2.0 (or higher), two 
double-sided disk drives, at least 512 
Kbytes, an d a graphics adapter (CGA, 
EGA, VGA, or Hercules) plus a suit¬ 
able monitor. Windows/386 obviously 
requires and only runs on an 80386-based 
machine. In addition, it requires DOS 
3.1 (or higher), at least 1 Mbyte of 


extended or expanded memory, one 
high-density floppy disk drive, and a 
hard disk. 

So much for minimal requirements. 

In our use, where we wanted to take full 
advantage of Windows, we concluded 
that we needed a hard drive, lots of 
memory, an EGA or VGA graphics dis¬ 
play with a color monitor, and a mouse. 
More specifically, we found that Win¬ 
dows 2.03 works best with at least 1 
Mbyte, so we could use the SmartDrive 
disk-caching system; Windows/386 
needed at least 3 Mbytes if we wanted 
to load many tasks and run them con¬ 
currently. By the way, either version 
takes about 1.5 Mbytes of hard-disk 
space. 

Installing Windows was easy, thanks 
to a setup utility that requires nothing 
more than a few answers to questions 
about the underlying machine, the dis¬ 
play, the printer, and the mouse. We 
needed to change the config.sys and 
autoexec.bat files as well. Finally, a 
win.ini file containing various system 
parameters allowed us to customize our 
installation down to the level of key¬ 
strokes, file extensions, and what appli¬ 
cations to load and start when Windows 
boots up. 

The excellent manual that comes with 
the system describes the win.ini file. In 
addition, since win.ini is an ASCII file, 
it includes sufficient comments that we 
could easily edit it with any text editor 
without having to refer to the user’s 
manual to know what to add or change. 


Using Windows. Starting Windows 
using the keyboard is quite simple, 
either on a system with two floppy-disk 
drives, or from a hard disk (in this case, 
it helps to have the directory containing 
the Windows files in the Path environ¬ 
ment variable so you can start Windows 
from any directory). But ending a Win¬ 
dows session is a little bit more compli¬ 
cated. You must close or exit all 
applications before you can exit Win¬ 
dows. While applications written specif¬ 
ically for Windows feature a close or 
exit command in the pull-down menu, 
you can terminate non-Windows appli¬ 
cations only in their normal fashion. 
The latter situation means that you 
must switch from application to appli¬ 
cation as you shut each one down. 

Starting Windows from the DOS 
command prompt automatically 
invokes the MS-DOS Executive win¬ 
dow. From this window you can start 
up other applications by selecting their 
file names with the keyboard or a 
mouse. A neat feature of Windows is 
that you can select a file name by typing 
its first letter. This highlights the file 
name in reverse video. Pressing the 
enter key starts up the selected appli¬ 
cation. 

An application can take one of three 
forms once started: the entire screen, a 
variable-sized window, or an icon. You 
can move and size windowed applica¬ 
tions. Scroll bars along the sides of the 
window allow you to view any part of 
the partially displayed screen image. 
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You can move icons, too, but this 
generally does not seem very useful. 

Every windowed or full-screen dis¬ 
play includes a top border containing 
the control-menu box, the title bar, 
minimize/maximize boxes, and possibly 
a menu bar. When selected, the control 
menu drops down to offer six options: 
restore, move, size, minimize, max¬ 
imize, and close the window. You can 
select the option by typing the appropri¬ 
ate letter, by hitting an Alt-function key 
combination, or by clicking the mouse. 
The minimize/maximize boxes offer a 
faster way to change the window using 
the mouse. Finally, to restore a window 
or icon, you can press Alt-Tab (or Alt- 
Esc) to avoid passing through the con¬ 
trol menu. 

For those applications specifically 
written for Windows, the menu bar 
offers additional options unique to the 
application. For example, the MS-DOS 
Executive offers a file, view, and special 
command set related to what files are 
displayed and how (by name, date, size, 
or kind); what files to run, load, delete, 
rename, print, or copy; and the special 
commands used to create and change 
directories, format disks, make system 
volumes, set a volume name, or end the 
Windows session. Additional Windows 
applications, such as the clipboard, the 
card file, or the terminal emulator, have 
different menu bars, while non-Windows 
applications have none. 

Another very useful feature of Win¬ 
dows, dialog boxes appear when an 
application needs information from the 
user to carry out a command. A dialog 
box includes a text box in which you 
type your message, a list box in which 
you select one item from the many 
presented, a group of check boxes from 
which you can choose as many as you 
want, a group of option buttons from 
which you can choose only one, and a 
group of command buttons to carry out 
the commands. 

Admittedly, it took some time before 
we became familiar with all the sym¬ 
bols, notations, and terminology, but 
after that we began to fly through all 
the windows. However, we did need to 
“install” applications not specifically 
written for Windows, which requires 
the program information files (or 
PIFs). 

The PIF editor is itself a Windows 
application that appears as a dialog 
box. For each program we responded to 
the dialog entries by typing in a name 
and a title along with the program 
parameters needed to start the program. 
Thus, if you would normally start up 
your editor as “NE myfile.txt,” then 
the program name is “NE” and the 
parameters are “myfile.txt.” Since we 


would normally execute the program in 
a specified directory, the initial direc¬ 
tory field allowed us to specify the drive 
and directory from which our window 
application would start. 

The memory requirements field of 
the PIF includes both the minimum and 
desired kilobytes of memory. Other 
fields include program switching, screen 
mode, and automatic closing of the 
window when we exited an application. 
For Windows/386, another choice is the 
usage control. On a 386-based machine 
you can run an application as a full 
screen, a background, or an exclusive 
application. The exclusive mode is use¬ 
ful if you want to devote all the system 


Windows/386 worked 
exceedingly well with every 
conceivable application. 


resources to that particular application. 
Alternatively, the background mode is 
great if the application requires less 
resources and can be delegated to the 
background while other applications get 
better service in the foreground. By the 
way, since Windows normally uses the 
mouse for selecting information to be 
cut or copied, the mouse can only be 
used by an application running in full¬ 
screen or exclusive-display mode. 

Windows applications. To make 
things interesting, Microsoft includes a 
number of desktop applications specifi¬ 
cally written for Windows; a notepad, 
card file, calendar, calculator, clock, 
game, terminal, drawing facility, and 
word processor. 

The notepad, calendar, calculator, 
terminal, and clock applications are 
pretty much what you would expect. 
Each has its own set of menu-bar com¬ 
mands that includes, in addition to the 
list given earlier, a cut, copy, and paste 
command for moving text and graphics 
between applications. You can make 
each application into an icon to recall as 
needed. An interesting feature of the 
clock application is that it continues to 
display the correct time even as an icon. 
Also, unlike non-Windows applications 
where the icon is a square enclosing the 
first three letters of the application 
name, the Windows applications have 
unique icons that serve to remind you 
of what the application does. All appli¬ 
cations written specifically for Windows 


can be closed from the control menu, 
whereas other applications must be 
explicitly closed using the normal termi¬ 
nation procedure of the program. 

The desktop game, called Reversi, is 
not particularly exciting, but it does 
help to pass the time away. 

The card file is a nice feature if you 
like an automated Rolodex system that 
can dial numbers as well. What makes it 
more valuable is the cut and paste fea¬ 
ture of Windows, which allows you to 
move text between the card file and any 
text editor or word processor. 

The word processor, Write, is a 
stripped-down version of Microsoft 
Word. Write commands allow you to 
create, edit, format, and print docu¬ 
ments. You can choose these commands 
from the menus on the menu bar at the 
top of the Write window. The format¬ 
ting commands let you change on the 
screen the appearance of the characters, 
the spacing and alignment of the lines in 
each paragraph, and the page layout for 
printing. 

The drawing tool, Windows Paint, 
lets you create, modify, save, and print 
black and white artwork. It provides 
many tools for creating drawings, mak¬ 
ing flowcharts, or doing freehand illus¬ 
trations. Commands such as zoom in or 
out, copy, and invert make it easy to 
enhance your work. The real beauty is 
that you can transfer text and graphics 
from other programs to Paint for easy 
editing and enhancement, or create 
Paint graphics to use in other Windows 
applications. 

Windows/386 worked exceedingly 
well with every conceivable application 
(such as CAD, telecommunications, 
word processing, and desktop publish¬ 
ing programs). We did encounter one 
serious problem: With fast typing, 
characters that should have appeared in 
the current window were either lost or 
magically found their way to a previ¬ 
ously opened command.com window. 

We also noted a few minor annoy¬ 
ances, including: (a) a serial port given 
to a specific application could not be 
recaptured by Windows unless we 
closed the application; (b) occasionally, 
after we had opened and closed many 
applications, the remaining applications 
seemed to slow down; and (c) some 
applications seemed able to change the 
color palette, affecting the colors dis¬ 
played by all Windows applications. 

Two really important features of 
Windows/386 make it extremely useful. 
First, each application running in a win¬ 
dow can essentially have a full 640 
Kbytes of memory (or more using the 
built-in expanded memory support) in 
which to run. This makes it possible to 
run large CAD or desktop publishing 
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hDC Computer’s Windows Express 


programs that normally can only run on 
the bare system. In addition, Win¬ 
dows/386 supports the LIM 4.0 
expanded memory specification for 
those programs that can take advantage 
of it. 

Second, Windows/386 can support a 
network environment. First you install 
the network, then bring up Windows. 
We tried this out with LANtastic NOS 
and were rather surprised and then 
pleased to see how well it worked. 

Recommendations. We think 
Microsoft Windows is one of the best in 
its category and recommend it highly. 
The power and the low price of Win¬ 
dows/386 are enough to make you won¬ 
der if it isn’t a better buy than OS/2, 
particularly in the way it effectively uti¬ 
lizes the underlying 80386 machine. For 
those with an XT or 286, Windows 2.03 
is an excellent alternative operating 
environment that makes using the PC a 
lot easier and certainly more fun. 

Windows 2.03 retails for $99, while 
Windows/386 costs $195. 

Windows 2.03: Reader Service 20 
Windows/386: Reader Service 21 


The first Windows 
application to buy 

Microsoft has publicized Windows a 
lot lately with ads that tout the large 
number of applications being written 
for it. Applications include desktop 
publishing, clip art, drawing packages, 
neural-net simulations, games, word 
processors, and so on. The variety 
arises from the large number of Win¬ 
dows developers. However, to my way 
of thinking, everyone should purchase 
one specific product first. 

The product is Windows Express 
(previously ClickStart) from hDC Com¬ 
puter Corp. It is such an obvious appli¬ 
cation that it makes you wonder why it 
isn’t a part of Windows. As a direct 
replacement for the MS-DOS Executive 
screen that you would normally use, 
Windows Express offers a hierarchy of 
menus so that you can select an applica¬ 
tion with a single keystroke or by click¬ 
ing on it with a mouse. A part of the 
program, Windows Express Editor 
(previously ClickEdit), lets you create 
and edit these menus so that you can 
tailor them to your specific envi¬ 
ronment. 

Users will normally place Windows 
Express in the win.ini file so that it 
comes up running as soon as Windows 


starts. Each item on the menu screen 
includes an icon, a letter key to select 
the application, and a description of the 
application to be executed. Actually, 
since the menus can extend to several 
levels, a menu item (called a folder) that 
selects a lower-level menu appears in 
bold while the application to be run 
(called a program) appears in bold 
italics. As you descend through folders, 
a stack of nested folders appears at the 
top of the screen. 

Windows Express provides a rich 
menu structure that won’t match up 
with the applications you have on your 
system. But the reason for doing this is 
obvious; it allows you to develop your 
own menus by “copying” the folders 
and program descriptions, and by 
“editing” them to describe your unique 
environment. That’s where Windows 
Express Editor comes in. Operating just 
like Windows Express, the editor lets 
you describe the program with its name, 
description, selection key, initial 
drive/directory, and program 
parameters. If you want, it will even put 
up a dialog box asking for a file name 
and providing a list of files to choose 
from. 

What makes all of this more interest¬ 
ing is that you can create or edit the 
icon for each folder and program. Each 
has its own default, of course, but once 
you’ve seen the ones hDC supplies with 
its own set of menus, you’ll probably 
decide to customize. At the very least 
you’ll want to chose ah icon’s color, if 


only to make your menus more 
interesting. 

Windows Express also features a 
password field and a help screen. The 
password provides a rather modest 
form of protection, because a knowl¬ 
edgeable user can get around it by sim¬ 
ply leaving Windows. The help screen 
assists beginners who may need some 
additional information before starting a 
program. You need not invoke either of 
these features; they’re just unobtru¬ 
sively there if you want them (like most 
of the other features). 

From what I understand, writing a 
Windows application is not easy. That 
may account for the $79.95 price of the 
Windows Express package. Because I’d 
expect most Windows users to purchase 
this application, it would be nice to see 
a lower price—the profits can be made 
up in volume. Still, I thoroughly 
enjoyed using the program and recom¬ 
mend it highly. 

Reader Service 22 


Multitasking with multiple 
users 

The advertisements for PC-MOS/386 
(MOS for Modular Operating System) 
offer a number of reasons to choose 
this alternative operating system. To 
begin with, MOS is designed for the 
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80386 and is PC and PS/2 compatible. 
It’s also upwardly compatible with 
thousands of existing DOS programs 
and applications, and it uses familiar 
DOS commands like Copy, Dir, Erase, 
and Format. MOS is also a multitasking 
and multiuser operating system that can 
support from one to 25 simultaneous 
users with full security and file/record 
locking. Finally, it’s reasonably priced 
at $195 in the single-user version, or 
$595 and $995 for the five- and 25-user 
versions, respectively. 

What intrigued me most about MOS 
was its modular structure, which allows 
the user to tailor the operating system 
to the hardware environment on which 
it will run. The “modular operating sys¬ 
tem” means that you can add and 
replace the various modules that make 
up the base system. Most users are 
already familiar with this type of envi¬ 
ronment, where special device drivers 
install RAM disks and disk caches, cre¬ 
ate and manage expanded and extended 
memory, set terminal characteristics, 
and load networking BIOS routines. In 
the case of MOS, this capability is much 
more extensive. It includes setting up 
the type of memory management sup¬ 
ported, the multiuser time-slice value, 
the system-memory-pool size, the num¬ 
ber of simultaneous users, user security, 
special-character devices to buffer and 
“pipe” information between partitions, 
and serial-device characteristics for all 
the display terminals that connect to the 
host machine. 

The modularity makes it possible to 
run this operating system on the full 
spectrum of machines in the 80x86 
family. A read.me file gives configura¬ 
tion examples for a PC XT; PS/2 
models 30, 50, 60, and 80; an 80286; 
and an 80386. Also included are com¬ 
mands for setting up a four-user sys¬ 
tem, a two-user system with a print 
spooler, and a three-user system with an 
outgoing modem line. Various memory 
management devices are supported in 
addition to that found on the 286 and 
386, including the Charge Card and All 
Card. But I’ll not dwell on this, because 
my real interest in testing MOS was to 
find an operating system that would uti¬ 
lize the capabilities of the 386 micro¬ 
processor to the fullest. 

Installation. Installing a five-user ver¬ 
sion 2.10 of MOS is a snap. First you 
boot your system from the MOS 
floppy, which brings up PC-MOS/386. 
Next you copy the MOS system files to 
an appropriate hard-disk subdirectory, 
placing three system files in the root 
directory. Then you use the MOS com¬ 
mand .msys (note that all MOS com¬ 
mands begin with a “.”) to write the 


boot sector on the hard disk (just as you 
would with the equivalent DOS Sys 
command). Finally, you create appro¬ 
priate config.sys and autoexec.bat files. 
A reboot will now bring up the full 
system. 

But note from the above that you can 
start up from a floppy. The package 
includes an evaluation system that runs 
for 30 minutes before requiring a 
reboot. This allows you to test PC- 
MOS/386 before either committing to it 
or taking advantage of the 30-day 
money-back guarantee. When you 
decide to keep the system, you break 
the seal on a package containing 
another floppy that replaces the evalua¬ 
tion modules with the complete system. 
The modular design allows you to 
update and expand the system as you 
move from a less- to a more-powerful 


PC-MOS/386 divides 
memory into partitions, 
assigning a fixed amount 
of memory to a partition 
and not an application. 


system, say from an AT to a 386 or 
from a single-user to a multiuser envi¬ 
ronment. 

MOS supports larger disk volumes 
than the current DOS limit of 32 
Mbytes per partition, and this leads to 
another unusual installation feature: 
dividing your hard disk into two sepa¬ 
rate but bootable partitions. As a result, 
you can keep both MOS and DOS on 
your hard disk and be prompted each 
time you boot as to which partition to 
activate. This will prove quite valuable 
for the few applications, like inter¬ 
preted Basic, that do not run under 
MOS. 

Partitions, or what is PC-MOS/386? 

One thing MOS is not is a windowing 
system; nor does it utilize virtual mem¬ 
ory. Instead, this operating system 
divides memory into partitions, where a 
fixed amount of memory is assigned to 
a partition and not to an application. 
Partitions can range in size between 32 
Kbytes and 640 Kbytes. A system com¬ 
mand lets you adjust the size of the par¬ 
tition both when created and during 
use. 

Switching between partitions follows 
pressing a combination of the Alt and 
numeric keypad keys. The first parti¬ 
tion, which must always be present, is 


partition 0. The size of this partition 
determines the maximum size of all 
other partitions, so it’s a good idea to 
make this partition a full 640 Kbytes. 
Actually, the upper limit isn’t 640 
Kbytes but something less, depending 
on the display adapter used. This occurs 
as a result of the virtual screen image 
being stored within the partition. 

Partition 0, also known as the base 
partition, serves many uses. Obviously, 
you can run applications in this parti¬ 
tion. But part of the memory in parti¬ 
tion 0 is used for the system memory 
pool, or SMP, used to dynamically allo¬ 
cate space for device drivers and other 
system-support modules. An advantage 
to the SMP implementation is that you 
can both load and unload modules dur¬ 
ing system use. If you’re running on a 
machine without memory management, 
then all other partition memory also 
comes from this base partition. How¬ 
ever, if your machine supports memory 
management, then the operating system 
allocates it using the appropriate 
hardware. 

Creating additional partitions is done 
with the .addtask command. Not only 
does this determine the partition ID and 
amount of memory, it also specifies a 
start-up batch file, the serial port con¬ 
nected to this partition, and the security 
class. A complementary .remtask com¬ 
mand lets you remove a partition, and 
the .mos utility command facilitates dis¬ 
playing partition information, disabling 
keyboard input, waiting for an event, 
assigning an interrupt vector (IRQ) to a 
partition, setting video mode, handling 
printer output, and resizing a partition. 
Of particular interest is the IRQ assign¬ 
ment, since this could become a prob¬ 
lem with multiple tasks and users. MOS 
solves the problem by requiring manual 
assignment (and deassigment) to a par¬ 
tition. 

To run an application, you must load 
it into a partition of the appropriate size 
and start it up. You do this by switching 
to the partition using the Alt-numeric 
key combination, then typing the name 
of the program as you would in DOS. 
Because each partition can specify the 
display adapter type with the .mos 
Vmode command, you can set up 
different partitions for monochrome, 
CGA, EGA, Hercules, and VGA dis¬ 
plays. This makes sense when you have 
multiple displays connected to the sys¬ 
tem using the serial ports. I tried this 
with a VT100 connected to the two 
standard serial ports, Coml and Com2. 
This worked well and made my 386 
look like a real time-sharing machine, 
provided that the applications I ran 
understood the terminal type and didn’t 
try to manage the VT100 as if it were a 
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graphics display. The program supports 
a wide variety of terminals, including 
PC-type terminals, the ADDS View¬ 
point, the Televideo 910, the IBM 3101, 
and ANSI terminals, just to mention a 
few. 

With multiple partitions and tasks 
and only one display, there’s the issue 
of what to do with display data for a 
non visible partition. In MOS, all parti¬ 
tions maintain a virtual display that is 
updated as the application continues to 
run. Thus, display data is always cur¬ 
rent when a nonvisible partition 
becomes visible. 

Another MOS utility command speci¬ 
fies the partition priority. This com¬ 
mand can change the default priority 
assigned to all partitions, raising it from 
its assigned value of 2 to the highest 
value of 7, or lowering it to 0. The print 
spooler also uses a priority scheme. It is 
implemented as a disk-resident utility 
with many of the features found in 
sophisticated mini- and microcomputer 
packages. 

As you might expect, file formats for 
MOS are compatible with the format 
used in DOS. A directory map, how¬ 
ever, uses a full 80 columns, providing 
more than the usual DOS information 
for such things as file attributes, file 
class, the ID of the user who created the 
file, and the time and date the file was 
created. 

MOS includes a number of other 
extended DOS commands that increase 
the system’s utility. All of this is 
covered in the excellent documentation 
that comes with the software. Even nov¬ 
ice users will find the manual more 
thorough than that for DOS, and the 
complete index and table of contents 
will rapidly point the reader to the sec¬ 
tion that contains the relevant infor¬ 
mation. 

As mentioned earlier, the program 
offers a full set of MOS commands 
similar to DOS, invoked with a dot in 
front of the name (such as .ed). A 
command-line editor built in to the sys¬ 
tem allows you to recall and edit previ¬ 
ous commands—a very handy feature 
to have. In many cases you can use a 
DOS command or utility. The tradi¬ 
tional utilities, like the line editor, 
linker, and debugger, as well as the 
backup and restore, have been replaced 
by more-useful MOS programs much 
the way the Norton utilities and editor 
have supplanted the standard DOS pro¬ 
grams. One surprise is to find the sys¬ 
tem responding with “What?” rather 
than “Bad command or file name” 
when you type an unknown command. 

Security and protection. PC- 

MOS/386 implements security by 


assigning one of 26 classes to users, par¬ 
titions, directories, and files. A special 
file contains records that describe a user 
ID, a password, and one of four access 
levels for each of the 26 classes. The 
access levels are none, execute only, 
read and execute only, or unrestricted 
access. The .class command assigns a 
security class to a directory, while the 
.adduser command contains a field for 
implementing the class of a partition. A 
.signon command exists for user-level 
security, complemented by a .signoff 
command. The .copy command allows 
changes to the security class of a file. 
Advanced security includes encryption 
of files. 

The security feature of MOS is one 
aspect of how it supports record and 
file locking/sharing through access con¬ 
trols and passwords. Another method is 


VM/386 uses a 
virtual-machine manager 
to create, control, and 
remove a set of 
virtual machines. 


through the NetBIOS emulation that 
MOS provides. By installing 
Snetbios.sys as a device, the system 
effectively provides network-adapter- 
card compatibility. Each MOS partition 
then emulates an adapter card as if it 
were running on a separate computer. 
Partitions communicate using the emu¬ 
lator in the same way they would using 
NetBIOS installed on different machines. 

Overall assessment. Generally speak¬ 
ing, I liked PC-MOS/386 and found it 
to be a much-needed alternative operat¬ 
ing system for the IBM PC and compat¬ 
ible marketplace. The operating system 
performed better than some of the alter¬ 
native operating environments that 
depend on DOS. The enhanced com¬ 
mands and improved standard utilities 
(like the line editor, debugger, print 
spooler, and linker) showed that the 
implementors at The Software Link 
paid attention to what users and 
programmers need and have come to 
expect in an operating system. 

Like any new system, MOS turned up 
with some minor glitches. Specifically, 1 
encountered: (a) screen color changes as 
a result of switching back and forth 
between tasks, (b) the NumLock key 
light turning on and off at strange 
times, (c) lots of screen images flashing 


by as I switched between partitions, and 
(d) a frequently hung-up keyboard as a 
result of running certain programs that 
MOS did not support (such as inter¬ 
preted Basic). With the exception of the 
last problem, none of these are serious 
and certainly not much worse than I’ve 
found in early releases of other operat¬ 
ing systems. As a result, I would cau¬ 
tion that such problems may occur, but 
I wouldn’t recommend against using 
MOS. 

Probably the most serious problem 
was not knowing which applications 
would run and which would hang up 
the machine. The manual doesn’t pro¬ 
vide a list and it would be impossible to 
do so given the tens of thousands of 
applications existing. Thus, you will 
have to try for yourself, taking advan¬ 
tage of the money-back guarantee if 
necessary. All of the programs 1 tried, 
except for interpreted Basic, worked, so 
my set of applications fits rather nicely 
into the MOS scheme of things. 

Like DOS, which it replaces, MOS 
lacks a lot of the pizzazz found in win¬ 
dowing environments. MOS is a work¬ 
horse that implements the features and 
functionality of a minicomputer-based 
system on a micro. That may not be 
exciting, but it is much needed and I 
congratulate The Software Link for 
making it available. 

Reader Service 23 


The Professional 
MultiTasker 

IGC calls its virtual machine software 
(or VM/386) “The Professional Multi- 
Tasker.” Having worked this system 
over, I have to agree. Unlike other such 
systems, this one not only works well, 
but seems to be unbreakable. I have yet 
to find either an application that did 
not run on VM/386 or one that brought 
the system down. I cannot say that for 
the other systems covered in this issue. 

The idea behind VM/386 is not 
unlike Windows/386 or PC-MOS/386. 
Namely, each uses the virtual 8086 
mode of the 80386 to create a series of 
virtual machines. Unlike Windows but 
like PC-MOS, VM/386 does not create 
multiple windows displayed simultane¬ 
ously. Instead, it uses a virtual machine 
manager (VMM) to create, control, and 
remove a set of virtual machines. 
Invoking the Switcher brings one of the 
virtual machines to the foreground, 
where it becomes visible. Actually, the 
VMM is itself a virtual machine, albeit 
one with special features, so it, too, is 
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brought to the foreground whenever 
needed. 

Besides its bulletproof nature, 
VM/386 has a number of features that 
set it apart from the other systems. 
Probably the two most notable are that 
each virtual machine has its own con- 
fig.sys and autoexec.bat file, and each 
virtual machine can be brought into the 
foreground and rebooted using the typi¬ 
cal Ctrl-Alt-Del key combination. 
Another nice touch is that the system 
automatically includes a disk cache and 
a shared RAM disk, plus an expanded- 
memory manager. 

Installation and tutorial. You install 
VM/386 in a multistep fashion that, 
although automatic, requires you to 
reboot your machine twice. You must 
modify your normal config.sys and 
autoexec.bat files to remove memory- 
resident and protected-mode programs. 
The reason is obvious: the virtual- 
machine mode of the 386 does not allow 
complete virtualization to the extent 
that you get another 80386 machine, 
but rather a less-powerful 8086. Thus, 
you can’t run VM/386 on top of 
VM/386 like you can on true virtual- 
machine monitors. But no matter, what 
you get is really quite slick for the 386 
microprocessor. 

Having installed and then run 
VM/386 so that it intercedes between 
the 386 hardware and DOS, you can go 
through the tutorial part of the manual 
to learn how to use your new operating 
environment. First you learn about the 
Switcher and how to call it using the 
SysRq key. Next you create some vir¬ 
tual machines so that you can gain 
familiarity with the various screens and 
menus that create, terminate, update, 
and reboot a virtual machine. You also 
learn how to update a virtual-machine 
profile (used in creating a virtual 
machine) or a start-up file that initiates 
all the virtual machines you might want 
when you begin VM/386. 

At this point you see how to link a 
device to a virtual machine. Since 
VM/386 requires the user to allocate 
devices to virtual machines, rather than 
doing so automatically, it simplifies the 
process of sharing. Only the disk, key¬ 
board, and display are shared; all other 
devices must be assigned. Devices can 
be assigned exclusively to prevent access 
by other virtual machines, or can be 
shared and therefore float between vir¬ 
tual machines. 

For nonsupported devices, a univer¬ 
sal device driver in the first virtual 
machine runs a network, a tape backup, 
or a digitizing tablet. Novell and 3-Com 
Plus token rings are supported. Unfor¬ 
tunately, the LANtastic network 


reviewed in this issue is not. But you 
can understand this because different 
devices have rather critical timing con¬ 
straints, making it hard to support such 
devices universally. 

Fine-tuning your virtual machines. 

Given the various space and timing 
needs of the devices and the virtual 
machines, VM/386 allows you to fine- 
tune each machine and the overall sys¬ 
tem with a large number of parameters. 
A fairly extensive set of menus comes 
up when you invoke the Switcher. You 
move from one menu to the other with 
the Tab (or Shift-Tab) key. You select 
an item in a menu with the up/down 
arrow keys, and change it by typing in a 
new value. While a number of standard 
profiles describe a virtual machine, 
usually by the amount of base memory 
it is created with, other parameters have 


VM/386 allows you to 
view the memory 
content of 

virtual-machine addresses. 


to do with the amount of extended and 
expanded memory allocated, the boot 
device (floppy or hard disk, etc.), and 
the config and autoexec files to boot 
with. 

Additional parameters include the 
order in which a virtual machine will get 
external interrupts, the scheduling 
queue priority, and the time-slice 
amount in milliseconds. You can also 
allow the virtual machine to get real 
timer ticks and set whether or not the 
virtual machine will run at I/O privilege 
level 3 or 0. But most interestingly, you 
can enable a system-resource monitor to 
pass control on to the next virtual 
machine if the current one appears not 
to be utilizing its time slice. Because the 
check is based on I/O utilization, it can 
be fooled by computation-bound tasks. 
Thus, you can turn this feature on and 
off, and set parameters relating to the 
minimum number of seconds a virtual 
machine can run before being sus¬ 
pended and before it resumes execution. 

Going back to the boot device, let me 
explain why this isn’t simply your hard 
disk. Because VM/386 allows you to 
run different versions of DOS in each 
virtual machine, you need some way to 
bring DOS up. By booting from a 
floppy system disk, you work around 
the boot block on your hard disk. This 
means not only that you can multitask 


using different virtual machines, but 
also that you can have DOS 2.1 running 
on one machine and DOS 3.3 on 
another. A feature like that comes in 
handy if you’re trying to track down a 
bug that may be related to the version 
of DOS you’re running. 

Speaking of debugging, VM/386 not 
only includes some nice status reports 
regarding your use of system resources, 
but also allows you to view the memory 
content of virtual-machine addresses. 
While this feature may not be for casual 
users, it can make for some interesting 
debugging for sophisticated ones. 

How do you switch between virtual 
machines? Simple, you invoke the 
Switcher from where you select a virtual 
machine from the menu list. The one 
catch here is that going from virtual 
machine to virtual machine takes one 
extra step over other systems. However, 
the folks at IGC recognized this, and in 
the latest version I tested (1.2), a double 
SysRq combination simply and rapidly 
moves between virtual machines. Other 
new features increased system perfor¬ 
mance and supported both larger disk 
partitions and nonstandard disk parti¬ 
tion drivers. 

Testing the virtual machine environ¬ 
ment. I ran a great many of my stan¬ 
dard applications under VM/386 and 
they all behaved exactly as they would 
on the bare DOS machine. These appli¬ 
cations included Procomm Plus, CAD- 
KEY, Word, Multiplan, Leading Edge 
Word Processing, and Page Perfect. 1 
cite these, of the many I tested, because 
they represent the standard communica¬ 
tions, CAD, word processing, spread¬ 
sheet, and desktop publishing programs 
that most of us might try. Even more 
impressive was running DESQview 
(DV) on a virtual machine with 
expanded memory. You might call this 
multi-multitasking! 

I noticed one oddity when it came to 
DV. The DV memory-status window 
displayed the total expanded memory 
and the total expanded memory avail¬ 
able, but it always showed zero for the 
largest expanded memory available. 
While everything worked fine, this 
meant that I could not tell how frag¬ 
mented expanded memory was becoming. 

Whenever I had a question, technical 
support was there with a friendly voice 
and complete answer. Of course, some 
of my questions could have been 
answered by the excellent documenta¬ 
tion that comes with the system. The 
manual is very thorough and includes 
chapters on virtual machine concepts, 
installation, the tutorial, basics of 
VM/386, tailoring VM/386 to your 
applications, VM/386 and your hard- 
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ware, and a complete discussion of the 
many VMM screens. The appendixes 
include troubleshooting and 
screen/error messages. In-depth infor¬ 
mation and caution messages are high¬ 
lighted by boxes. 

If all of this were not enough, the 
program offers three kinds of context- 
sensitive screen help. FI explains the 
highlighted entry field; F2 provides help 
with the current screen; and F3 provides 
a key summary for the arrow and menu 
select keys. You can select a menu item 
by its item number on a list, and you 
always know where you are in the hier¬ 
archy of menus because of the scheme 
of numbering submenus with a .n nota¬ 
tion (such as 1.2.1). 

By the way, IGC claims that support¬ 
ing multiple virtual machines requires 
around 3 percent of system overhead. I 
tested this with a performance bench¬ 
mark and measured just slightly more 
than 3 percent. That’s darn good con¬ 
sidering the underlying complexity of 
VM/386. 

System requirements. Obviously, 
VM/386 needs a 386 machine as well as 
a floppy drive (a high-density one). 
While you could run it without a hard 
disk, that would be foolish. The system 
takes up nearly a megabyte of disk 
space, and it would be tough to switch 
between applications using a floppy. In 
addition, you will need at least 2 
Mbytes of RAM. I had 4 Mbytes, which 
I found more acceptable for many full 
640-Kbyte virtual machines. Graphics 
support includes all the standard dis¬ 
play adapters, but frankly I think it 
would be foolish to use anything less 
than an EGA or VGA board. 

IGC has tested VM/386 with at least 
12 different computers and boards to 
verify compatibility. I had no problem 
with my Micronics 386 board, VGA dis¬ 
play adapter, and 40-Mbyte hard disk. 
Users of Compaq, Tandy, PCs Limited, 
Orchid, Kaypro, Intel, Wedge, and 
Multitech (Acer) computers should also 
have no problems. In the case of the 
Compaq and Micronics systems, where 
these machines reserve the 384 Kbytes 
between 640 Kbytes and 1 Mbyte as sys¬ 
tem memory, VM/386 can get some of 
it back. This is unlike other expanded- 
memory software I have tested, which 
just says it isn’t there. As a result, 1,920 
Kbytes is available instead of 1,664 
Kbytes (as was the case when I ran 
QEMM-386 and DESQview). 

Recommendations. For me, this was 
a real pleasure of a review. The soft¬ 
ware worked as advertised and never 
crashed during all the tests I ran. I 
know it’s not as easy as it sounds to 


take advantage of the virtual 8086 mode 
of the 386, but VM/386 sure makes it 
look that way. Given all of this, I heart¬ 
ily recommend IGC as the best of the 
bunch for generating a neat virtual- 
machine, multitasking environment. 
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The test machine 

Running all of the different operating 
environments was a time-consuming 
and difficult task. Fortunately, I suc¬ 
cessfully completed the job. 1 thought 1 
ought to describe the test machine for 
those who may not have read my earlier 
review on 386 machines (see the April 
1988 issue of Computer). 


There are lots of great 
buys in clone machines. 
The important issue is 
software compatibility. 


For all of the different systems, I 
used a clone computer from PC-Genius 
with fairly standard components: a 
1.2-Mbyte, 5%-inch floppy drive; a 
40-Mbyte Seagate hard drive; a Western 
Digital combined floppy- and hard-disk 
controller; a Paradise VGA card plus 
display adapter; a Heritage multisync 
monitor; and a Micronics 386 mother¬ 
board running at 20 MHz with 4 
Mbytes of main memory and an 80387 
coprocessor. 

Probably the most important compo¬ 
nent has been the Micronics mother¬ 
board. In talking with some of my other 
reviewers, I found that their machines 
would not run one or another of the 
operating environments. Clearly their 
problems were not with the disks or dis¬ 
play adapters, since these were “stan¬ 
dard” components. More by luck than 
anything else, I happened to use a 
machine that maintained compatibility 
with both the AT and the Compaq 
Deskpro 386 systems. 

One of the first things I did to con¬ 
duct the tests, however, was to upgrade 
from the standard 1 Mbyte of memory 
to 2 Mbytes. That was easy, requiring 
only that I plug in additional 256-Kbyte 
memory chips on the memory board. 
When testing Windows/386,1 found 
another 2 Mbytes would be necessary to 


open more than a couple of windows. 
Again, this was easy because Micronics 
makes a piggyback to the memory 
board that snaps into place. However, 
because my motherboard does not have 
a cache and uses 80-nanosecond chips, I 
can’t easily take the next step to six or 
more megabytes. 

Micronics does make a motherboard 
with a cache so that slower 1-Mbit chips 
can be used to get a full 16 Mbytes of 
32-bit memory. But that wasn’t the 
motherboard available to me at the time 
I bought my computer. Still, I’m not 
altogether out of luck. I can add a 
16-bit extended-memory board if 1 
really want to have more than the 4 
Mbytes I now have. 

The point of all of this is to make you 
aware that there are lots of great buys 
in clone machines. However, the impor¬ 
tant issue is software compatibility. 

Will your machine run DOS, Unix, 
Xenix, and OS/2? Has the manufac¬ 
turer tested all of these systems, or just 
claimed that since the machine is a 
“true” clone it will most probably run 
all of them? If you wanted something a 
bit more exotic, like Windows/386, PC- 
MOS/386, VM/386, or DESQ- 
view/QEMM-386, would it run on your 
new machine? 

Don’t take anything for granted. I 
changed the BIOS ROMs in my 
machine because I was having some 
small but annoying problems. As a 
result, I’m much more pleased with my 
system and have had a much easier time 
testing all of the operating environ¬ 
ments. Will this help you on your 
clone? Or for that matter, can you 
replace one manufacturer’s ROM in 
your machine with another’s? Note that 
BIOSs are not all organized the same 
electrically. 

OS/2 might cause some problems, 
because each vendor will have to supply 
the support software that relates to the 
I/O architecture. Small companies 
might not have the necessary resources 
to write the code quickly. However, if 
they’ve copied a machine from a larger 
vendor who already has the code, you 
may be in luck, because that version of 
OS/2 will work on your machine as 
well. 


for the end use r. I 
werit With Micronics and as a result 
everything has worked out well. In fact, 
_I heartily r e commend Micron ics to all 
of you considering a 386. Still, 1 have to 
admit that I was more lucky than smart. 
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A fantastic, full-featured network 

Dick Eckhouse, New Product Reviews editor 


Many issues back, I did a review on 
an entry-level networking system. This 
low-priced system offered disk, Com, 
and printer sharing so that one machine 
could remotely access peripheral devices 
between machines. Shortly thereafter, 1 
got a call telling me that I hadn’t seen 
anything yet and that I would soon 
receive something I’d like even better. 

Actually, the call really piqued my 
interest because this new LAN offered 
more features and functionality for less 
money. I’ve got to say that the caller 
lived up to his word and his LAN is 
aptly named LANtastic. This complete 
system from Artisoft includes a net¬ 
work interface adapter and a network 
operating system. 

To install the system, you plug the 
adapter into any 8-bit slot and connect 
your machines together with the 
shielded dual-twisted-pair cable 
included with the system. 1 installed 
boards in my Compaq Deskpro, Desk- 
pro 286, and 386 clone and linked them 
together in a typical LAN bus 
fashion—one machine to the next. The 
cable connector is a 9-pin D-type, with 
a male and female connector on each 
board. After stringing the machines 
together, I plugged a terminator into 


the open connectors at each end of my 
net. By the way, even though this 
cabling technique looks like a route- 
through rather than a tap, network 
operation continues when one of the 
machines connecting the other two is 
not running or is powered off. 

The next step was to bring up the net¬ 
work operating system. The automatic 
procedure requires only that you type in 
the command Net_mgr. Subdirectories 
are created on your hard disk and all 
the necessary files are copied from the 
floppy. You can start up the network 
from a batch file, using one of the 
several included on the floppy. Essen¬ 
tially, the startup entails loading the 
LANBIOS and REDIRector software 
and then using the Net_mgr command 
to establish the links. 

Before 1 go into more detail about the 
software, let me describe the hardware. 
The half-slot adapter cards should work 
in just about any machine. Each 
includes a 10-MHz coprocessor with 32 
Kbytes of memory for managing the 
network. The transfer rate is 2 Mbits. 
Links can extend more than 500 feet, 
using shielded cable. While you can put 
up to four adapters in one machine, 
thereby creating gateways between nets, 


I did not test this capability. 

The network protocol is CSMA/CD 
and CSMA/CA. No I/O ports or DMA 
channels are used, although you must 
set the IRQ level and specify where the 
32 Kbytes of memory are located above 
the base (640-Kbyte) boundary. A 
check-out program called, appropri¬ 
ately, LANcheck verifies that every¬ 
thing is working correctly. 

All of this is carefully explained in a 
separate user’s manual. The manual 
also explains some of the optional 
parameters if you want to configure the 
system differently from the defaults. 
Other chapters discuss performance 
considerations and error messages. 

If you’re like me, you will just want 
to get this LAN up and running. In that 
case, you’ll need to read the Network 
Operating System User’s Manual. 

Here’s where you’ll learn how to not 
only share devices, but control access to 
files, send net mail, and provide net¬ 
work security. Amazingly enough, all 
of this is possible at a cost of less than 
10 Kbytes of memory per network 
workstation and less than 40 Kbytes of 
memory per server. Okay, but what do 
I mean by workstation and server? 

Machines that utilize resources on 
another machine are workstations; 
those that provide the resources are 
servers. The LANtastic Network Oper¬ 
ating System (LNOS) allows any com¬ 
puter to be a workstation or a 
combination of workstation and server. 
It does this by implementing the Net¬ 
BIOS software in each coprocessor so 
that with DOS 3.1 or later, full file and 
record locking is implemented using the 
DOS Share command. While not all 
applications software supports file and 
record locking, that which does is fully 
supported by LNOS. 

Let’s get back to LANtastic. First 
you need to set up the drives and files 
accessible by the network users. These 
links let a network user access the sub¬ 
directory \Payroll from a workstation 
by mapping the file to a server’s 
C:\Accounting\Payroll file. Associated 
with the link is an access control list 
(ACL) that specifies file read, write, 
create, delete, and rename operations as 
well as make, lookup, and delete direc¬ 
tory operations, plus program execution 
and even physical-device access. 

How are these files associated with 
users? For each user or user class, there 
is an ACL for a particular network sub¬ 
directory or printer. For example, the 
user Bill might have directory lookup 
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and execute files. The user class 
Admin*, meaning anyone with a user 
name starting with the letters Admin, 
such as Admin-Dick, could have read, 
write, create, and delete access as well 
as program administration. All of this 
goes in the user account file along with 
some other parameters such as pass¬ 
word and user description. Two other 
parameters specify the number of con¬ 
current logins for the user and account 
privileges such as the ability to modify 
the ACLs, to view and modify the jobs 
in the print and mail queues, to disable 
some of the Share program checks, or 
to create audit-trail entries. 

Yes, this system includes a full set of 
audit trails for full accounting of net¬ 
work usage. Also possible is full printer 
control for such things as banners 
separating jobs, form-feed control, tab 
and paper widths, printer rate control 
when the CPU is heavily loaded, a setup 
string to initialize the printer, and, of 
course, an ACL. The setup string is 
handy if you want to create multiple 
printer devices using the same physical 
printer but different setups. An exam¬ 
ple might be two setup strings, one to 
set the printer to compressed draft 
mode and the other to set it to near let¬ 
ter quality. 

All of the above is accomplished 
either using the network software, 
which operates as a series of pop-up 
menus, or as command lines. In the 
beginning, I found the menus best when 
I wanted to go very carefully through 
and familiarize myself with the multi¬ 
tude of features that LNOS possesses. 
Once I had created my file links, ACLs, 
and users, I could then use the com¬ 
mands in a batch file that not only 
brought up the workstations and 
servers, but also logged me into the 
servers so that the files and printers 
were immediately available for use. 

Having mastered this marvelous sys¬ 
tem, I started to use it. Transferring 
files was easy because it was the same 
old Copy command using a new sub¬ 
directory. Executing programs was 
equally easy, since 1 just typed in the 
program name preceded by the correct 
drive or subdirectory. (If I had added 
the new subdirectory to my Path, I 
would have only needed to type in the 
program name.) The time it took to 
access a file or load a program didn’t 
differ noticeably from what it would 
take if the file or program were locally 
resident on my hard disk. Printing 
remotely was just as simple. 

Since everything worked so smoothly 
and easily, 1 decided to try something 1 
thought would be a bit more difficult. 
Since 1 had a tape backup on one 
machine and not another, I wanted to 


use it to back up an entire hard disk 
remotely. Amazingly enough, the tape 
backup ran full speed because the 
floppy controller speed was less than 
the network link. Wow, buying a LAN¬ 
tastic system cost less than a tape 
backup, and now I had both for the 
price of the network alone. 

My next test was to use LANtastic 
with my Leading Edge Word Processor 
(LEWP). I did so because LEWP was 
already set up to use a network, albeit a 
Novell network. Foolishly, 1 figured 
what the heck and gave it a try. The 
first thing I noticed was LEWP’s error 
message that program Nprint was miss¬ 
ing. Not knowing what Nprint did, I 
wrote a tiny Quick Basic program to see 
what was passed to Nprint. As one 
might expect, the parameters had to do 
with which server and which printer 
were to be used over the network, as 
well as the file to be sent. I added a few 
more lines to my Basic program to issue 
the required net commands and voila, 
everything worked; I was able to net¬ 
work print my LEWP files. 

I could go on and sing the praises of 
the LANtastic system, but what’s the 
point? I found it to be a real winner 


Product notes 

• A new service from Ontrack Com¬ 
puter Systems retrieves data from 
hard disks that have gone haywire 
due to power failure, aging, and 
other failures such as controller 
card, interface board, and network 
faults. Information concerning data 
recovery is available by calling (800) 
752-1333, or writing to Ontrack at 
6200 Bury Dr., Eden Prairie, MN 
55346. 

• The Ultimate Databinder from 
International Computer and Office 
Products, phone (404) 373-3683, 
offers an easy way to fasten 300-400 
pages of computer printout that can 
be opened flat, held upright with an 
A-frame stand, and conveniently 
stacked. These binders are much 


both in terms of price and performance. 
For $399 you get a starter kit that 
includes two network adapters, 15 feet 
of cable, the network terminators, and 
a single-server license for LNOS. Each 
additional adapter and 15-foot cable 
costs $199. An unlimited LNOS license 
for $295 will allow you to connect up to 
120 systems. 

Minimum system requirements are a 
PC with 256 Kbytes, one floppy drive, 
and one 8-bit slot. The hardware sup¬ 
ports most other NetBIOS-compatible 
network operating systems, but LNOS 
seems more than enough for me. While 
the current version of the network mail 
facility is primitive, it is easy to jazz it 
up using your favorite higher-level lan¬ 
guage and making command-line calls 
to LNOS. 

I like this local area net, I find it easy 
and very convenient to use, and I think 
it is really LANtastic. So go out and 
buy this package if you want to link up 
your PCs. You won’t be disappointed, 
and you’ll find it offers you networking 
capabilities heretofore found mostly on 
minis and mainframes. 
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more convenient than the older style 
that typically clamp the upper inch 
of a listing. While sold direct, the 
binders are available through many 
mail-order computer-supply com¬ 
panies. 

• Rayovac, a company well-known 
for its flashlight and 9-volt batteries, 
now markets an $18 computer clock 
battery for 80286 and 80386 
machines. Based on a reportedly 
unique alkaline technology, these 
4.5-volt batteries work longer than 
the typical 6-volt lithium batteries 
they replace. While available from a 
nation-wide list of stocking distribu¬ 
tors, they can also be purchased at 
most Radio Shack stores. 
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IBM launches AS/400 family for small- and 
medium-sized companies 


IBM has announced the Application 
System/400, a family of six business- 
oriented computers sharing a single 
operating system and tied to other IBM 
products by the company’s Systems 
Application Architecture. 

All models run on IBM’s Operating 
System/400, which offers a relational 
database, menu-driven interface, and 
on-line tutorial. Each system includes a 
time-of-day clock and automatic pro¬ 
gram loading to help ensure continuous 
operation during power outages. 

The BIO and B20 are compact floor¬ 
standing models offering 4 Mbytes of 
main storage. The models include a 
workstation controller, two 315-Mbyte 
disk units, a X-inch tape cartridge unit, 
and an IBM Token-Ring LAN adapter. 
Model BIO is designed to support 
between four and 12 users, while the 
B20 supports between eight and 20 

The models B30, B40, B50, and B60 
are modular, rack-mounted systems 
that can grow to as many as 11 rack 
enclosures. According to the company, 
users who start with a B30 can upgrade 
to a B60 by adding modules. Main stor¬ 
age ranges from 4 Mbytes (B30) to 32 
Mbytes (B60). 


Meta Software has announced 
Design/OA for the IBM PC and 
Microsoft Windows. The new develop¬ 
ment tool reportedly helps program¬ 
mers design customized object-oriented 
graphics applications. The software is 
based on Design/2.0, a graphics and 
text processor. 

According to the company, 
Design/OA provides a horizontal sup¬ 
port environment, so that the developer 
modifying an application interfaces 
with high-level support tools rather 


The AS/400 system processor uses 
single-level storage, which reduces pro¬ 
gramming complexity by having the sys¬ 
tem automatically store data in the most 
efficient way; 48-bit addressability, 
which reportedly allows application 
programs to be virtually unlimited in 
size; VLSI logic, and a 32-bit data path. 

In addition, the company claims its 
Systems Application Architecture pro¬ 
vides a consistent framework and inter¬ 
face with other IBM systems. For 
example, a LAN workstation user 
reputedly can access data from an 
AS/400 or another IBM host system, 
communicate with all other users in the 
network, perform jobs on the AS/400 
from an IBM PC or PS/2, and use the 
AS/400’s attached printers. 

As part of its product introduction, 
IBM also announced the availability of 
more than 1,000 software packages for 
the AS/400, including a number of 
packages that have been migrated from 
the company’s System/36 and Sys¬ 
tem/38. IBM expects more than 2,500 
application packages to be available by 
August, when shipments of the new 
models are scheduled to begin. 

Reader Service 34 


than with the operating system. 

Design/OA costs $7,500. The soft¬ 
ware and its derived applications will 
run on an IBM PC-AT, compatible, or 
higher performance machine supporting 
Microsoft Windows/286 or Win¬ 
dows/386. The company recommends a 
PS/2 Model 70 or 80, a Compaq 386, 
or close compatible with 3 Mbytes of 
RAM. Applications may also require a 
386-based machine. 
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HP bases workstation on 
Motorola 68030 CPU 

Hewlett-Packard has announced a 
workstation based on Motorola’s 68030 
microprocessor. The HP 9000 Model 
360 uses Motorola’s 32-bit CPU and an 
MC68882 floating-point coprocessor, 
both running at 25 MHz. It reportedly 
achieves speeds of up to 5 MIPS. The 
company also plans to introduce a 
workstation based on a 33-MHz version 
of the MC68030. The Model 370 will 
reportedly perform at more than 7 
MIPS. 

Model 330 owners can convert their 
systems to the Model 360 with a single¬ 
board kit costing $5,950. A similar kit 
for $5,000 will allow Model 360 owners 
to upgrade to a Model 370. 

According to the company, cus¬ 
tomers can transfer their software from 
existing workstations to Model 360 by 
verifying their compiled software code 
with HP-UX 6.2, which follows 
AT&T’s Unix System V Interface Defi¬ 
nition Issue 2. The HP-UX operating 
system reportedly also provides com¬ 
patibility between Motorola-based HP 
workstations and RISC-based HP Pre¬ 
cision Architecture systems. 

Configurations of Model 360 range 
from $ 15,550 for a diskless monochrome 
system with 4 Mbytes of RAM to 
$62,950 for the Model 360 TurboSRX 
with 8 Mbytes of RAM and HP’s 3D, 
solid-rendering graphics subsystem. 

Hewlett-Packard has also introduced 
the HP 9000 Model 319SRX, a solids- 
rendering graphics workstation that 
combines the company’s SRX graphics- 
accelerator technology with 32-bit HP- 
UX system processing. Model 319SRX 
can be configured as a stand-alone 
workstation or as a diskless node in a 
network. It features the MC68020 CPU 
running at 16.7 MHz, with an MC68881 
floating-point coprocessor. A standard 
system costs $25,000. 
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Compaq steps up PC performance with new 386 models 



Compaq Computer has added two 
models to its family of 80386-based per¬ 
sonal computers, the DeskPro 386/25 
and the DeskPro 386s. 

The DeskPro 386/25 combines the 
25-MHz Intel 80386 chip with Com¬ 
paq’s Flex architecture, which uses the 
25-MHz Intel 82385 cache memory con¬ 
troller operating with its own 32 Kbits 
of static RAM. Sockets on the system 
board reportedly permit the addition of 
the 25-MHz Intel 80387 and 25-MHz 
Weitek 3167 coprocessors. Operating 
system options include Microsoft’s 
OS/2 Standard Version 1.0 and MS- 
DOS Version 3.3, as published by 
Compaq. 

Model 110 features a half-height 
110-Mbyte fixed-disk drive with an inte¬ 
grated controller, track buffering, and 
1:1 interleave. It costs $10,299. 

Model 300 features a full-height 
300-Mbyte fixed-disk drive with a 1:1 
interleave, track buffering, and mul¬ 
tipurpose ESDI controller. It costs 
$13,299. 

Both models include a 5X-inch 
1.2-Mbyte disk drive; 1 Mbyte of 32-bit 
RAM; six expansion slots; parallel and 
asynchronous communications inter¬ 
faces; real-time clock/calendar; security 
lock; enhanced keyboard; 192W steady- 
state power supply; Expanded Memory 
Manager; Disk Cache software; and 
one-year limited warranty. 

The 32-bit DeskPro 386s uses the 
16-MHz Intel 386SX microprocessor 
and a VGA graphics controller. It runs 


MS-DOS Version 3.3 and Microsoft’s 
OS/2 Version 1.0 as published by 
Compaq. 

Model 1 includes 1 Mbyte of 
enhanced page memory, a 5^-inch 
1.2-Mbyte disk drive, parallel and asyn¬ 
chronous communications interfaces, 
an auxiliary input interface, a socket for 
a 16-MHz 80387SX coprocessor, secu¬ 
rity keylock and keyboard password 
security, a real-time clock/calendar, 
Expanded Memory Manager software, 
a disk-caching utility, and an enhanced 


keyboard. It features four available 
8-/16-bit expansion slots and one high¬ 
speed memory expansion slot. Model 1 
costs $3,799. 

Model 20 has the same features as 
Model 1, but adds a 20-Mbyte fixed- 
disk drive. It costs $4,499. 

Model 40 has the same features as 
Model 1, but adds a 40-Mbyte fixed- 
disk drive. It costs $5,199. 

DeskPro 386/25: Reader Service 38 
DeskPro 386s: Reader Service 39 


CAE/CAD systems tailored to specific design tasks 


The Advansys Series of computer- 
aided engineering and design systems 
from Daisy Systems consists of turnkey 
systems tailored to specific design tasks, 
according to the company. Each runs 
the SunOS Unix operating system. 
Hardware configurations available are 
based on the Sun Microsystems Sun386i 
workstation or Daisy’s 80386-based 
workstations, the Logician 386 and Per¬ 
sonal Logician 386. 

Advansys systems come with stan¬ 
dard communications and distributed 
processing capabilities. They can 
reportedly be networked to a variety of 
shared resources for computation¬ 
intensive tasks. Shared resources 
include Daisy’s Sun-4-based XL Server, 
the PMX physical modeling system, 
and the GigaLogician and MegaLogi- 
cian hardware accelerators offered 


by Daisy. 

Standard system-level software 
includes the SunOS, TCP/IP communi¬ 
cations software, and Sun’s ONC/NFS. 
The initial release of the series also 
includes MIT’s X Window System for 
graphics. 

Each system includes a 386-based 
workstation, standard system environ¬ 
ment, and integrated applications pack¬ 
age. Several configurations are 
available for each system, depending on 
application and user requirements. 

The Design Entry System includes a 
schematic editor, design compilers, a 
basic component library, and packag¬ 
ing/reporting programs for printed- 
circuit-board layout. It costs $23,000. 

The Design Analysis System includes 
the design entry package, the Pattern 
Editor application for editing wave¬ 


forms, and network-access tools for 
logic simulation on remote accelerators. 
It costs $38,000. 

The Digital Design System can also 
access network simulation resources, 
but also includes the DLS II logic simu¬ 
lator on the local system. It costs 
$62,000. 

The Analog Design System includes a 
schematic editor, DSPICE circuit simu¬ 
lator, Virtual Lab analysis environ¬ 
ment, and a basic analog library for 
$54,000. An additional analog system is 
available, with access to simulation only 
over the network. 

Daisy plans to begin shipping the 
Advansys Series in September. Contact 
the company for information on avail¬ 
ability and configurations. 
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Intel 386SX CPU features 16-bit data bus 


Intel has introduced the 386SX, a 
32-bit microprocessor with a 16-bit 
external data bus. The company has 
begun shipping the 386SX to several 
customers and begun sampling to other 
computer manufacturers. 

According to the company, the 
386SX provides backward compatibility 
to 8086- and 80286-based software. 
Moreover, operating systems, applica¬ 
tions software, and operating environ¬ 
ments developed for 386-based systems 
will run unmodified on similarly con¬ 
figured 386SX-based systems. 

The company claims that the 
microprocessor’s 16-MHz clock speed 


Compulink Management Center 
offers the LaserFiche 3000 Series Sys¬ 
tem, which uses optical disks, optical 
scanners, and laser printers in an inte¬ 
grated document search, update, 
retrieval, and archival system. 

Users can scan hard copy into the sys¬ 
tem through the optical scanner, com¬ 
municate data from mainframe 
systems, send data to and from the sys¬ 
tem with modems or fax boards, or 
enter original data with the keyboard. 
The scanner can reportedly scan any 
font from 8 through 24 points in land¬ 
scape or portrait format, at a speed of 
40 characters per second. 

Users can update documents through 
word processing or an optional user 
interface. Scanning in documents from 
different word-processing systems, 
users can combine them into a uniform 
format and type style. 

Users can search the database of 
documents using single words, phrases, 
or fixed indexes. All words within a 
document serve as keys. 


allows it to execute at a sustained rate 
of 2.5 to 3 million 32-bit instructions 
per second, exceeding the performance 
of other microprocessors with a 16-bit 
external data bus. 

The 100-lead plastic quad flatpack 
package, JEDEC standard, reportedly 
was designed for surface mounting and 
consumes little board space. It costs 
$219 in volumes of 100 units. 

A variety of peripherals, coproces¬ 
sors, and development tools are avail¬ 
able for the 386SX, including the 
80387SX numerics coprocessor. 
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The LaserFiche 3000 system hard¬ 
ware consists of a 32-bit 80386 
microprocessor running at 20 MHz; 2 
Mbytes of 32-bit, 80-ns RAM; a mul- 
tisynchronous color terminal with 
640 x 400 resolution text and graphics; 
40-Mbyte and 300-Mbyte fixed disks; 
an intelligent character recognition, 
graphics and text scanner; an 
800-Mbyte WORM optical-disk storage 
system with an average access time of 
108 ms; a laser printer; and a streaming- 
tape backup system. 

The LaserFiche 3000 system software 
provides a search capability, indexing 
by word, an optional application- 
module interface to other CPUs, word 
processing, the MS-DOS 3.3 operating 
system, hardware integration modules, 
automatic I/O routines and font con¬ 
version, and optional graphic and desk¬ 
top publishing software. 

The LaserFiche 3000 Series System 
costs $45,000. 
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Macintosh system software 
evolves another step 

Apple has released Apple Macintosh 
System Software Version 6.0, the most 
recent operating system for the Macin¬ 
tosh PC family. According to the com¬ 
pany, the new version features enhanced 
system and MultiFinder capabilities, a 
MacroMaker program, CloseView, and 
Map utilities. 

Under MultiFinder, Apple’s mul¬ 
titasking operating system, users can 
open application documents directly 
from the desktop. The MultiFinder 
notification manager has more alerts to 
notify users that background tasks 
might require attention. 

MacroMaker allows users to create 
keyboard macros for mouse and key¬ 
board actions. CloseView permits mag¬ 
nification of the Mac screen. Map helps 
users determine the time and distance 
between locations worldwide. 

Version 6.0 costs $49. It is compatible 
with Macintosh computers having at 
least 1 Mbyte of memory. 
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VAXstation 2000 family 
adds 6 new members 

Digital Equipment has expanded the 
VAXstation 2000 family of desktop 
workstations with six new models. 
According to the company, the new 
models add color capabilities, a 
graphics coprocessor expanded to eight- 
plane capacity, and a memory module 
with total system memory capacity to 14 
Mbytes. 

The new VAXstations incorporate 
DEC’S MicroVAX II CPU and 
floating-point unit; a choice of a 
15-inch or 19-inch color monitor; key¬ 
board; mouse; and Ethernet controller. 
Systems are available with VMS or 
Ultrix operating systems. Local backup 
or storage options include 42-, 71-, and 
159-Mbyte hard disk drives; a 96-Mbyte 
streaming tape drive; and a 1.2-Mbyte 
floppy disk drive. 

An example of pricing would be a 
diskless VAXstation 2000 system with 
an eight-plane coprocessor, 6 Mbytes of 
system memory, and a 15-inch color 
monitor for $13,830. A similar system 
with 14 Mbytes of system memory costs 
$18,530. A variety of other configura¬ 
tions are available. 
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Compulink’s LaserFiche 3000 consists of (left to right) an optical scanner, optical 
disk drive, 80386-based computer, and laser printer, plus software for document 
search, update, storage, and retrieval. 


System searches, updates, and archives documents 
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ADVANCE ANNOUNCEMENT 


October 9-13,1988 
Castle Premier Hotel 



International Conference on Miami Beach - fl 

Computer 
Languages '88 


The International Conference on Computer Languages ’88 will begin on Monday, October 10,1988 with the following tutorials: 

■ Requirements Languages: Moving From the Solution Domain to the Application Domain, presented by Alan M. Davis, BTG, Inc. 

■ Object-Oriented Software Engineering, presented by Peter Wegner, Brown University 

■ Concurrent C, presented by Narain Gehani, AT&T Bell Laboratories 

The conference will formally open on Tuesday, October 11th with a keynote address delivered by Dr. Jack Schwartz (Director, DABPA/ISTO) entitled "Prototyping 
Technology in the DAB PA Strategic Software Technology Program.” 


Parallel Session covering the following topics will be presented o 

■ Application Languages 

■ Language Implementation 

■ Language Design I 

■ Distributed and Parallel Programming 

■ Language Design II 

■ Specification Languages-Assessment and Trends 

■ Directions in Computer Languages 

■ Object-Oriented Languages 

b Is Computer Language Obsolete? 


Tuesday, Wednesday and Thursday: 

■ Object-Oriented Programming Environments 

■ Specification Languages and Applications 

■ Beal-Time and Prototyping System Languages 

■ Al and Computer Languages 

■ Extending Al Languages 

■ Methodology and Support Environments 

■ Hardware Description Languages 

■ Knowledge & Bequirements Engineering 


Advance Registration Form 


Mail form or facsimile to: 

Glenda McBride 

International Conference on Computer Languages 
The Computer Society of the IEEE 
1730 Massachusetts Avenue, NW 
Washington, DC 20036-1903 


Please Type or Print: 

Name—- 

Affiliation--- 

City__State-Zip. 

Country_Work Phone- 

CS/IEEE Membership Number- 

Tutorials: Please check the tutorial you wish to attend: 

□ I. Requirements Languages, Alan M. Davis 

□ II. Object-Oriented Software Engineering, Peter Wegner 

□ III. Concurrent C. Narain Gehani 


Conference Registration Fees: 

Advance Registration Fees-Until September 16,1988 
Conference Only: 

Members = $205.00 Nonmembers = $255.00 Students = $45.00 
Tutorials: 

Members = $180.00 Nonmembers = $225.00 Students = $180.00 
Late/On-Site Registration Fees-After September 16,1988 
Conference Only: 

Members = $245.00 Nonmembers = $305.00 Students = $45.00 
Tutorials: 

Members = $200.00 Nonmembers = $250.00 Students = $200.00 

Method of Payment 

□ Personal Check □ Company Check 

□ Visa □ MasterCard □ American Express 

Card Number __,-1- Ex P- Date - 

Name as it appears on card- 

Signature 

For Office Use Only 

Date Received-■—.- 

Check No_;-Amount- 

PC-CC-— MO - 

Remarks ---- 


A block of hotel rooms are being held for ICCL attendees at the Castle Hotel & Resort at the special reduced rate of $66.00 for single and double roomsjo reserve a room 
please contact: The Castle Hotel & Resort, 5445 Collins Avenue, Miami Beach, FL 33140, (305) 865-1500. All reservations must be received by the hotel no later than September 19,1988. 









































Series 4000 workstation gets graphics 


Apollo Computer offers a 2D color 
graphics version of its Series 4000 Per¬ 
sonal Super Workstation. The new 
workstation combines a high-resolution 
color monitor and a dedicated graphics 
processor that reportedly increases 
graphics performance of the Series 4000 


by more than 100 percent. 

Features include eight bit planes of 
color and a l,280x 1,024 19-inch moni¬ 
tor with a 68-Hz refresh rate. 

Prices start at $20,990. 
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Alsys offers Ada compiler for OS/2 


Alsys has announced an Ada com¬ 
piler that runs under OS/2 on 80286- or 
80386-based machines. According to 
the company, the compiler can run on a 
machine with as little as 2 Mbytes of 
main memory, along with the OS/2 sys¬ 
tem (Version 1.0 of the Standard Edi¬ 
tion) provided by the machine’s 
manufacturer. 

The OS/2 Ada Compiler includes 
compiler, binder, multi-library environ¬ 
ment (family, library, and unit 
managers), run-time executive, standard 
Ada packages, and AdaWorld, the 
company’s common-user interface. 

The compiler includes the user- 
controllable high-level optimizer, which 


supports representation clauses and 
suppresses constraint checks. According 
to the company, the compiler is com¬ 
plemented by a set of programmer’s 
tools including AdaProbe, a high-level 
debugger; AdaReformat; AdaXref; and 
AdaMake. Sold with the compiler, all 
four together cost $800. Sold 
separately, they cost more. 

The OS/2 Ada Compiler for 
80286-based machines comes with a 
4-Mbyte memory board for $3,595. The 
OS/2 Ada Compiler for 80386-based 
machines costs $3,095. 

Compiler: Reader Service 46 
Toolset: Reader Service 47 


HP plans 5 new MAP 3.0 products 


Hewlett-Packard has announced five 
manufacturing-networking products 
meeting the MAP 3.0 specification for 
factory communications, plus a VLSI 
technology supporting the seven layers 
of the OS1 standard for multivendor 
networks. The software and hardware 
products target entry-level HP 9000 
Series 800 systems. 

The MAP 3.0 MMS, or manufacturing- 
message specification, software will 
provide a standards-based command 
language for programming MAP- 
compatible devices on the factory floor, 
according to the company. It is sched¬ 
uled for availability by the end of 1988, 
for a price not to exceed $2,500. 

The MAP 3.0 FTAM, or file transfer, 
access, and management, software will 
allow users to remotely transfer and 
access files across multiple computer 
systems. Planned for release in the first 
half of 1989, it will cost $1,500 or less, 
according to the company. 

The OS1 Express interface will con¬ 
nect HP computers to the network 
through broadband or carrierband 
cabling. It will implement the MAP 


portion of the seven-layer OSI protocol 
stack on a VLSI integrated card. It will 
include the MAP 3.0 nodal- 
management facility for local-computer 
configuration. Scheduled for the end of 
1988, it will cost no more than $5,000 
with carrierband cabling and no more 
than $6,500 with broadband cabling. 

The company plans to offer a device 
interface system by the end of 1988. 

The interface will connect HP com¬ 
puters to non-MAP, RS-232-C devices 
on the factory floor, or to non-MAP- 
device subnetworks. The price will 
reportedly not exceed $11,500, includ¬ 
ing a run-time license per system. 

The MAP 3.0 protocol analyzer will 
decode the seven-layer MAP protocol 
stack and monitor IEEE 802.4 traffic. 
The company plans to market the pro¬ 
tocol analyzer in the first quarter of 
1989 for a price not to exceed $50,000. 

MMS: Reader Service 48 
FTAM: Reader Service 49 
OSI Express: Reader Service 50 
Interface: Reader Service 51 
Analyzer: Reader Service 52 


WORM subsystem holds 
1.2 to 2.4 Gbytes 

N/Hance Systems offers the 5120 
write-once, read-many-times optical- 
disk subsystem for the IBM PC, XT, 
AT, and compatible computers. The 
WORM subsystem provides 1.2 Gbytes 
of storage on a double-sided 5%-inch 
removable cartridge. A two-drive con¬ 
figuration provides 2.4 Gbytes of 
storage. 

The 5120 WORM subsystem comes 
with the company’s TextScan 
document-management and text- 
retrieval software. 

N/Hance claims that the 5120 has 
90-ms average access times and a data 
transfer rate of 6.5 Mbits per second. 

The 5120 for internal mounting costs 
$6,188. It includes the drive, controller, 
installation software, TextScan soft¬ 
ware, and cables. The external version, 
which costs $6,388, includes a metal 
enclosure with dedicated power supply, 
cooling fan, controller, cables, and 
installation and TextScan software. The 
two-drive external version, the 5120/2, 
costs $9,688. 
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FlexCache hits 4.71 MIPS 


Advanced Logic Research has 
announced two desktop versions of its 
FlexCache computer with advanced 
cache memory and dual bus architec¬ 
ture. The 20386DT Model 401 is an 
80386-based system running at 20 
MHz with a 32-Kbyte memory cache, 
80387 support, a 1.2-Mbyte floppy disk 
drive, one serial port, one parallel port, 
and a 40-Mbyte hard disk drive. The 
Model R66 has a 66-Mbyte hard disk 
drive. 

According to the company, the Flex¬ 
Cache 20386DT rated 4.71 million 
instructions per second, based on the 
Power Meter Version 1.2 Benchmark. 

The standard configuration 20386DT 
comes with a 1-Mbyte, 32-bit memory, 
expandable to 2 Mbytes of RAM on the 
system board, with a possible total of 
10 Mbytes of system memory on an 
optional expansion card. It also fea¬ 
tures an intelligent look-ahead caching 
controller that reportedly performs with 
a 1:1 interleave. The system can accom¬ 
modate an additional 66- or 100-Mbyte 
hard disk drive. 

The Model 401 costs $4,490 and the 
Model R66, $4,590. 

Reader Service 54 
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Membership Application 


Membership dues and publication subscriptions are annualized to December 31. 
Pay the full-year fee if application is mailed September 1-February 29. 

Pay the half-year fee if application is mailed March 1-August 31. 


I COMPUTER SOCIETY ONLY (affiliate membership) 
You are eligible if you are seriously interested in any aspect of the 
computer field or if you are a member of one of the affiliate 
societies listed below. 

(Check all applicable societies.) sepn-Fe b2 9 

Affiliate Societies □ $19.50 □ $39.00 


[ COMPUTER SOCIETY MEMBERSHIP FOR 
IEEE MEMBERS. If you are presently an IEEE member, you 
may join the Computer Society for a nominal amount. (Complete 
only shaded area of application.) 


B □ American 1 1 _ 

I Astronautics (AIAA) 

I □ American Institute of Physics (AIP) 

f □ American Mathematical Society (AMS) 

Mechanical Engineers 


□ Instrument Society of America (ISA) 


for Computing Machinery (ACM) □ J^^tyof 



Management Association 

Society of Japan (IPSJ) 

jersTlEICEfofJapan 
Electrical Engineers (IEE-UK) 


□ Society of Automotive Engineers (SAE) 

□ Society for Industrial and Applied 
Mathematics (SIAM) 

□ Society for Computer Simulation (SCS) 

□ Society for Photo-Optical Instrumentatic 



) COMPUTER SOCIETY AND IEEE. In addition to your 
■ Computer Society benefits, you’ll receive many IEEE privileges 
and benefits. You are eligible if your technical interests are in 
computer science and engineering, the electrical and electronics 
fields, or related fields. Your entry membership grade will be 
determined by your level of participation, contributions, education 
and/or experience in those fields. 


Residence 

United States 

Canada . 

Europe, Africa, Middle East 
Latin America. 















































1C Announcements 


Company, Model, Function_Comments_ R.S. No. 


Adaptec 
AIC-6110 
SCSI controller 


Analog Devices 

AD770 

ADC 


A synchronous, SCSI, mass-storage controller with data transfer rates of 5 Mbytes/s; asyn- 120 
chronous rates of 3 Mbytes/s. Supports drive data-transfer rates up to 20 MHz. Provides 
software-programmable precomp. Does not offer data separation. Production in fourth 
quarter. Cost: $25 (1,000s). 

A monolithic, flash A/D converter with 8-bit output at 200-megasamples/s with 250-MHz 121 

full-power and 400-MHz small-signal bandwidths. Wide bandwidth for low distortion sam¬ 
pling of 100-MHz Nyquist-frequency signals. Features a proprietary error-correcting 
scheme. Comes in a 40-pin ceramic DIP. Cost: begins at $175 (100s). 


Hitachi America 

HM628128 

SRAM 


A high-density static RAM that stores more than 1 Mbit of data organized 8 bits x 128 
Kbits. Built on Hitachi’s 0.8-micron gate-width process. Typically consumes 1 mA of 
standby current. Comes in a 32-pin plastic DIP or surface-mount package, with speeds of 
70, 85, 100, and 120 ns. Production in first quarter 1989. Cost: $220 (70-ns DIP). 


Microwave Semiconductor A family of GaAs logic devices with pin-for-pin plug-in compatibility with 100K ECL 
G100K family devices. Includes a 6-bit adder, an 8-bit shift register, a carry look-ahead generator, and a 

GaAs logic devices quad driver. Available in 24-pin ceramic side-brazed DIPs with internal decoupling capaci¬ 

tors; 24-pin flatpacks planned. Cost: 2-2'A times the price of 100K ECL ICs. 


Motorola 
33-MHz 68030 
CPU 


A 33-MHz version of the 32-bit 68030 microprocessor. Includes on-chip instruction and 
data caches, on-chip memory management, parallel architecture, and dual modes of 
address. Compatible with other 68000 family microprocessors. Production planned for 
fourth quarter. Cost: $697 (100s). 


Sierra Semiconductor 

SC22100 

EEPROM 


Signetics 

PLS159A 

PLD 


A 256-bit EEPROM organized 32 x 8 bits, with an endurance specification of one million 
write/erase cycles and a data-retention device reliability of 25 years claimed by the com¬ 
pany. Features a redundant cell structure and complementary data storage. Needs no erase 
when a write cycle is performed. Comes in an 18-pin DIP. Cost: $5.87 (100s). 

A programmable logic sequencer with an 18.2-MHz operating frequency and a bipolar 
architecture. Has four dedicated inputs, four bidirectional I/Os, individual programmable 
output polarity, and eight registered I/Os. Comes in 20-pin plastic DIPs and PLCCs. Cost: 
$5.25 for DIP, $5.75 for PLCC (100s). 


Signetics Two 15-ns (max) PAL-type PLDs with low power consumption. PLHS16L8B has eight 

PLHS16L8B, PLHS18P8B dedicated inputs, two dedicated outputs, and six bidirectional I/Os. PLHS18P8B has eight 
PLDs more logic AND product terms, two more bidirectional I/Os, and programmable polarity 

control. Cost: (100s) PLHS18P8B: $4.33 for 20-pin plastic DIP, $5 for PLCC; 
PLHS16L8B: $3.75 for DIP and PLCC. 
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Standard Microsystems 
CRT97C11 View 
CRT controller 


Texas Instruments 

SN74ACT8818 

Microsequencer 


Toshiba 

TC58257AF/AP 

EEPROM 


Toshiba 

TC57H256D-70/80 

EPROM 


Weitek 

Abacus 

Numerics coprocessor 


View—Video Engine for Windows. A CRT controller to support, in hardware, the creation 128 
and manipulation of windows on a CRT screen. Supports bit-mapped graphics and 
alphanumeric applications, and up to 127 independent windows. Permits display data to be 
stored in virtual screens. Comes in a 68-pin PLCC. Cost: $32.35 (100s). 

A 16-bit, TTL-compatible microsequencer that can address up to 64K words of microcode 129 
memory. Performs multiway branching and conditional subroutine calls. Features a next- 
address generation time of 27 ns. Comes in 84-pin PLCCs. Cost: $48.80 (1,000s); $67.10 
for 84-pin PGA (third quarter). 

A 256-Kbit flash EEPROM. Comes in a 28-pin plastic DIP compatible with ultraviolet- 130 
erasable PROMs (TC58257AP) and a 450-mil-wide 28-pin flatpack (TC58257AF) with 
access times of 170, 200, and 250 ns for each. Production scheduled for September. Cost: 

(100s) $55 for TC58257AF; $50 for TC58257AP. 

A 256-Kbit EPROM with access times of 70 and 85 ns. Production scheduled for fourth 131 
quarter. Uses polycide for word-lines and gates of peripheral transistors. Consumes 210 
mW (min) during operation and 0.525 mW during standby. Organized 32K words x 8 bits, 
in a 28-pin ceramic DIP. No prices given. 

A 20- or 25-MHz single-chip version of the three-chip 1167 coprocessor for 80386-based 132 

PCs. Plugs into the extended math coprocessor socket. Includes a 32 x 32-bit register file, 

64-bit ALU, multiplier, and divide and square-root computation units. Comes in a 121-pin 
PGA. Production in October. Cost: $45 for 20-MHz, $882 for 25-MHz versions (5,000s). 
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Microsystem Announcements 


Company, Model, Function_Comments_ RS - No - 

Absoft A Fortran compiler based on RISC Architecture Technology, ported to A/UX on the 135 

MacFortran/AUX Macintosh. Meets ANSI Fortran 77, IEEE P754, and Mil-Std-1753 specs. Supports most 

Compiler VAX/VMS and many Fortran 8X extensions. Provides access to Unix, the Macintosh 

Toolbox, and interlanguage calling with C. Cost: $495. 

Amlan A series of ruggedized portable computers weighing 3.5 pounds. Features a display of 80 136 

Microscribe 700 columns x 8 lines, windowing onto a 24-line page; up to 1 Mbyte of RAM, and a mem- 

Portable computer brane keyboard with separate numeric keypad. Has built-in ports for RS-232 and serial 

devices. Firmware includes CP/M and Mallard Basic Interpreter. Cost: starts at $2,875. 


Applied Intelligent Systems 

AIS-3500 

Vision processor 


Boca Research 
Boca.MCA Serial/Parallel 
I/O board 

cisco Systems 
X.25 interface board 
Gateway interface 

Computer Peripherals 
Hook-Up 9600 
Modem 


General Micro Systems 
GMSV07-VSB-1 
CPU board 


Hayes Microcomputer 
Products 

Smartmodem 9600 
Modem 


Hi Pointe Instruments 
HPI-31 System 
I/O processor 


Keithley Instruments 
AMM2 

Data acquisition module 


National Instruments 
GPIB-VXI 
Interface board 


Radstone Technology 
68-31 

Single-board computer 


Strawberry Tree Computers 

L/T Control 

Software 


A dual-board vision system with 128 parallel processors for more than 600 million opera¬ 
tions per second. Supports up to six RS-170 cameras. Contains a 68000 host processor, a 
parallel array controller, and parallel image memory. Tabletop or rack-mout configura¬ 
tions. No price given. 

A I/O adapter board for the Micro Channel Architecture. Provides two RS-232 serial ports 
and one Centronics parallel port. Supports the Micro Channel shared interrupt scheme and 
is configurable at standard I/O port addresses. Cost: $210. 

A gateway interface for the creation of an X.25 backbone network operating at T1 speeds 
or faster, up to 4 Mbits/s. Plugs into a slot in the backplane of the company’s gateways. 
Also supports DDN X.25 specs. Cost: $1,750 per T1 port, plus X.25 software. 

A 9600-bps modem for IBM PC, XT, AT, PS/2 Model 30, and compatibles. Compatible 
with the Hayes command set, Bell 103 J and 212A standards, V.22 and V.22b.s standards, 
and CCITT V.29 standard in half duplex. Operates in synchronous or asynchronous modes 
with the MNP error-control algorithm up to level 6. Cost: $795. 

A 32-bit, 25-MHz CPU board based on the 68020 with a 68881 coprocessor. Allows VSB 
master/slave transfers between all CPUs in a system. Has up to 1 Mbyte of zero-wait-state 
dual-ported SRAM, up to 256 Kbytes of EPROM, two multiprotocol serial ports, and a 
configuration controller with timers. Cost: $2,917. 

A CCITT V.32-compatible modem for Data Communications Network applications. Pro¬ 
vides full-duplex, synchronous/asynchronous, 9600-bps and 4800-bps leased-line and dial¬ 
up communications. Implements Trellis Coded Modulation and Viterbi Decoding. Version 
2.0, available by the end of 1988, will support CCITT V.22bis, CCITT V.22, Bell 212A, 
and Bell 103. Cost: $1,999. 

Based on a plug-in I/O board (HPI-31) and A/D and D/A conversion modules (HPI-7600 
and HPI-7200) for the IBM PC, XT, AT, and compatibles. HPI-31 contains an 8031 
microcontroller, 2 Kbytes of dual-ported RAM, and an on-board 8255 that supports 24 
lines of digital I/O. Cost: $900 for HPI-31; $900 for HPI-7600; $450 for HPI-7200. 

Performs analog input, signal conditioning, and A/D conversion within the Series 500 
Data Acquisition System. Designed for slot 1 of the Series 500 workstation. Offers 50-KHz 
throughput and 16-bit A/D resolution. Supported through Soft500 Version 6.0 and 
Quick500 Version 2.0 software. Cost: $1,125. 

Links the IEEE-488 (GPIB) bus and the VXIbus (VMEbus Extensions for Instrumenta¬ 
tion). Performs transparent conversion of IEEE-488 signals and protocols so an IEEE-488 
controller can control VXIbus instruments. Shipments in September. Cost: $3,000 for 512 
Kbytes dual-ported RAM and firmware ROM. 

A 68030-based, 32-bit, VMEbus, single-board computer with a full VSB interface. Process¬ 
ing speeds up to 33 MHz. Includes 4 Mbytes dual-ported DRAM, optional 68882 floating¬ 
point coprocessor, cache burst-fill capability with zero-wait states, two synchronous or 
asynchronous serial ports, mailbox interrupts, and processor extension bus. Cost: $4,295. 

Factory automation software for process control using IBM PC XT and AT, PS/2 Models 
25 and 30, and compatible computers with the company’s hardware plug-in data acquisi¬ 
tion and control boards. Features graphical, real-time, animated data displays and high- 
resolution plots. Handles closed-loop PID control, on/off control, and alarm loops. Cost: 
$2,995; $1,495 for run-time version. 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing. COMPUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 
any of these phrases or similar ones: 
“...recent college grads...,” “...1-4 years 
maximum experience...,” “...up to 5years 
experience...,” or “...10 years maximum 
experience.” COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


UNIVERSITY OF TULSA 

The Department of Mathematical and 
Computer Sciences at the University of Tulsa 
invites applications for tenure track positions in 
Computer Science at junior and senior ranks 
to begin either in January or September of 
1989. Responsibilities include teaching 6 
hours per semester at the undergraduate and 
graduate level, continuing scholarly activity, 
and pursuit of extramural funding. Minimum 
qualifications are a Ph.D. in computer science 
or a related discipline and a strong commit¬ 
ment to teaching and research. Candidates 
with research specialties in Parallel and Scien¬ 
tific Computing, Computer Graphics, and 
Knowledge Based Systems are of particular 
interest; however, all research areas will be 
considered. 

The Department of Mathematical and 
Computer Sciences offers the Ph. D. degree in 
Computer Science; has a VAX 11/750, two 
MicroVAX II systems, and ten Sun 3 systems 
for faculty and student research; and is a 
member of NSFnet and BITnet. 

Applications will be evaluated beginning 
September 15, 1988. The position will be 
considered open until filled. Send vita, 
transcripts, and three letters of reference to: 
William A. Coberly, Chairman; Mathematical 
and Computer Sciences; University of Tulsa; 
600 S. College; Tulsa, OK 74104. The Uni¬ 
versity of Tulsa has an Equal Opportunity/ 
Affirmative Action Program for students and 
employees. 


NAVAL POSTGRADUATE SCHOOL 
Position Announcement in 
Computer Science 

The Department of Computer Science has 
immediate openings for faculty positions at all 
levels. Our primary interests are in the areas of 
operating systems, distributed systems, pro¬ 
gramming languages, and algorithms. Our 
secondary interests are in the areas of process¬ 
ing of visual data, real-time systems, and soft¬ 
ware engineering. An applicant should have a 
PhD in Computer Science or a related field 
and have a strong interest in both graduate 
teaching and research. Senior applicants must 
have distinguished research records. Appoint¬ 
ments can begin at any time during the year. 

The Department offers MS and PhD 
degrees in Computer Science. Departmental 
facilities (supported by 9 full-time computer 
professionals) consist of six instructional and 
research laboratories including the Database 
Systems Laboratory, the Graphics and Video 
Laboratory, the Software Engineering Labo¬ 
ratory, the Microcomputer Systems Labora¬ 
tory, the Artificial Intelligence Laboratory and 
the Computer Science Academic Laboratory. 
In these laboratories are the latest, state-of- 
the-art computing equipment including LISP 
machines, high-performance graphics work¬ 
stations, bit-mapped graphics workstations, 
multi-microprocessor systems, etc. During the 
academic year, the faculty normally teach for 
two quarters and conduct full-time research 
supported by major research programs in both 
the Department of Defense and the non-DOD 
organizations during the other two quarters. 
New faculty receive initial support from an on- 
campus research foundation. 

Located on Monterey Bay, the areas of 
Monterey, Pebble Beach, and Carmel pro¬ 
vide a pleasant Northern California coastal 
climate and easy access to Silicon Valley com¬ 
panies and universities. 

Please send a detailed resume and three 
letters of reference to: 

Search Committee 

Computer Science Department (Code 52) 
Naval Postgraduate School 
Monterey, CA 93943 
Tel. No. (408) 646-2449 

AN EQUAL OPPORTUNITY/AFFIRMA¬ 
TIVE ACTION EMPLOYER. 


INDIANA UNIVERSITY CYCLOTRON 
FACILITY (IUCF) 

Control System Programmer 

The Indiana University Cyclotron Facility is 
inviting applications for a full time, continuing 
position of Control System Programmer 
(CSP) to participate in the support of a 
dynamic laboratory of international reputa¬ 
tion. The duties and responsibilities of this 
position will include the following: Maintain all 


existing application software for IUCF control 
system computers. This includes correcting 
errors, changing programs to conform to 
changing modes of accelerator operation, and 
upgrading programs to improve efficiency, 
ease of use by operations staff, and level of in¬ 
tegration with each other and normal opera¬ 
tions. Maintain complete and timely backups 
for control system software on the control 
computers. Generate new software as 
directed in conjunction with normal IUCF 
facility expansion, improvement and ex¬ 
ploitation. Participate in the planning of 
control system expansions, new functions 
and retrofitting of old devices. Retrofit soft¬ 
ware developed for the “Cooler ring" into 
cyclotron operations. Act as consultant to 
any technicians/operators who are program¬ 
ming on the control system and to operators 
using the control system. Document control 
system software for operations staff, and for 
programming staff. Generate and modify, as 
appropriate, RSX-11M and RSX-11M-PLUS 
operating systems. 

The CSP must have a good working 
knowledge of FORTRAN and assembly lan¬ 
guage, preferably on a PDP/LSI-family com¬ 
puter. The CSP is expected to have or gain 
detailed knowledge of the RSX operating 
system family. A BS degree in science, 
engineering, or math, or equivalent ex¬ 
perience is required. 

Send resume and names of three refer¬ 
ences by September 30, 1988 to: 

Robert Woodley 

Indiana University Cyclotron Facility 

2401 Milo B. Sampson Lane 

Bloomington, IN 47405 

(812) 335-5194 

Indiana University is an Affirmative Action/ 
Equal Opportunity Employer. 


ATLANTA UNIVERSITY 

Computer Science: Tenure track assistant 
professor. Salary commensurate with qualifi¬ 
cations: Ph.D. in Computer Science (Ph.D. 
candidates also considered), preferred exper¬ 
tise in any one of the following areas: 
operating systems design; knowledge based 
and expert systems; computer hardware; 
computer communications. Duties: teaching 
graduate level courses; conducting spon¬ 
sored/unsponsored research; application 
deadline: August 25, 1988. Send letter of ap¬ 
plication, resume, transcripts, and three letters 
of recommendation to: Dr. Nazir A. Warsi, 
Chairman, Department of Mathematics and 
Computer Sciences, Atlanta University, 223 
James P. Brawley Drive, S.W., Atlanta GA 
30314. 

Atlanta University is an Equal Opportunity 
Affirmative Action Employer. 
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THE AUSTRALIAN NATIONAL 
UNIVERSITY 


UNIVERSITY OF CENTRAL FLORIDA 
ORLANDO, FLORIDA 

Computer Science Faculty Position 

The Department of Computer Science has 
openings for faculty positions in the rank of 
Assistant Professor, effective August, 1988. 

Applications for professorial positions must 
have a Ph.D. in Computer Science or a re¬ 
lated discipline to Computer Science. We 
desire an individual with interest in both 
research and teaching in one of the core areas 
of Computer Science. Areas which are of par¬ 
ticular interest include Architecture, VLSI 
design, Parallel Processing, Computer Vision, 
Programming Systems, Artificial Intelligence, 
Data Bases, and Algorithms Design and 
Analysis. 

Computer Science at the University of Cen¬ 
tral Florida is a comprehensive program. We 
offer programs leading to the Ph.D., M S., 
andB.S. degrees. Our departmental research 
facilities include a VAX 11/780, Harris 
HCX-9, HP-9000, Sun 3/60’s, a VAX 
11/730, a PDP 11/44, a microcomputer lab¬ 
oratory, and a VLSI design laboratory. 

The Department of Computer Science has 
been designated as a Center of Excellence for 
Computer Science in the State of Florida and 
an endowed chair funded by private industry 
and state money has been established in the 
department. 

Please send letters of interest and resume 

Dr. Amar Mukherjee, Chair 
Department of Computer Science 
University of Central Florida 
Orlando, Florida 32816-0001 
TEL: (407) 275-2341 

An Equal Employment Opportunity (M/F) 
Affirmative Action Employer. 


SCIENTIFIC PROGRAMMER/ 
ANALYST 

GSC, ranked as one of the nation’s TOP 
100 Small Companies, seeks scientific pro¬ 
grammers and analysts for our current in¬ 
volvement in software development for 
USEPA. Projects include: data base manage¬ 
ment; data integration; user interface systems 
development; and mapping and graphics 
related to environmental data. 

Preferred skills include willingness to solve 
complex problems, knowledge of DBMS 
systems, PL/I, and ISPF in an IBM 3090 
MVS/XA environment. Company offers 
competitive salaries advancement oppor¬ 
tunities, challenging work, and a complete 
benefits package. Please forward your resume 
in confidence to Pamela McLean: 

GSC 

6100 Chevy Chase Drive 
Laurel, MD 20707 


BOSTON UNIVERSITY 

Tenure track faculty appointment at the 
Assistant Professor level for individual to teach 
and conduct research in the fields of computer 
networks and ISDN, operating systems, com¬ 
puter architecture and distributed processing; 
to establish a networking laboratory, and to 
participate in new software engineering pro¬ 
gram. Ph.D. in computer engineering or 
related field, teaching, research and 
laboratory management experience in the 
fields of communication networks and com¬ 
puter controlled systems required. Interested 
persons should send resume and the names 
of three references to Prof. Thomas G. Kin¬ 
caid, Chairman, Electrical, Computer and 
Systems Engineering Department, Boston 
University, 44 Cummington Street, Boston, 
MA 02215. Boston University is an Equal Op¬ 
portunity/Affirmative Action Employer. 


COMPUTER SERVICES MANAGER 

Milwaukee Library System. Requires: ex¬ 
perience with Concurrent Computer or 
Perkin-Elmer mini-computer technology, real 
time transaction processing, and very large 
database management; 4 years C, COBOL 
and Assembler programming; BS in com¬ 
puter science or related; 4 years EDP ex¬ 
perience including 2 years of systems analysis; 
2 years of supervisory experience; and resi¬ 
dency in city within 6 months. Familiarity with 
Reliance operating systems desirable. Salary 
range: 35-50K. SEND RESUME or contact 
for more information: Sharon Rogers, (414) 
278-2029, City of Milwaukee, Personnel Box 
CSM, Room 706, City Hall, 200 E. Wells St., 
Milwaukee, WI 53202-3554. An Affirmative 
Action Employer. 


SOFTWARE ENGINEER 

40 hrs./wk., $28,000/yr. Responsible in 
writing software for microprocessors which 
will control the function of force measurement 
products. These microprocessors will be from 
the Intel 8096, Motorola 6800, and Rockwell 
6502 family of processors. Troubleshoot the 
programs and develop the hardware as re¬ 
quired for running the programs and control¬ 
ling the products. Assist manufacturing in 
building the products and marketing/sales in 
interfacing with customers to sell and solve 
any problem or unique applications requested 
by customers when the products are devel¬ 
oped. M.S. in electrical engineering preferred. 
2 years experience required. Apply to Job 
Service, 2005 B S. Elm-Eugene St., Greens¬ 
boro, N.C. 27406. Job order number NC 
7823400, DOT Code 020.061-640. 


Applications are invited for appointment to 
the position of LECTURER/SENIOR LEC¬ 
TURER, DEPARTMENT OF COMPUTER 
SCIENCE, FACULTY OF SCIENCE. The 
appointee will be expected to undertake 
research in an area of Computer Science, 
contribute to the Department’s undergraduate 
teaching program and to supervise graduate 
students. 

Applicants should have a Ph.D. in Com¬ 
puter Science (or a closely related discipline) 
and experience in Computer Science teach¬ 
ing and research. Preference may be given to 
applicants whose central interests are in the 
following areas: Information Systems/Data- 
base, Software Engineering, Artificial In¬ 
telligence, Computer Architecture, but ap¬ 
plicants with research interests in any area of 
Computer Science are encouraged to apply. 
Closing date: 2 September 1988. Ref: 
FS.9.6.1. SALARY: Senior Lecturer: 
A$38,216 - A$44,403 p.a.; Lecturer; A 
$28,694 - A$37,435 p.a.; APPOINTMENT: 
Lecturer/Senior Lecturer, tenurable. AP¬ 
PLICATIONS should be submitted in dupli¬ 
cate to the Registrar, The Australian National 
University, GPO Box 4, Canberra ACT 2601, 
quoting reference number and including cur¬ 
riculum vitae, list of publications and names of 
at least three referees. The University reserves 
the right not to make an appointment or to ap¬ 
point by invitation at any time. Further infor¬ 
mation is available from the Registrar. 

The University is an Equal Opportunity 
Employer. 


WEST VIRGINIA UNIVERSITY 
Electrical and Computer Engineering 

The Department of Electrical and Com¬ 
puter Engineering at West Virginia University 
anticipates available faculty positions for 1988 
and 1989 in the area of digital and computer 
engineering systems design. Salary and rank 
will be commensurate with qualifications. 
Positions will be tenure track. Applicants must 
have the Ph.D., potential for high quality 
teaching and will be expected to initiate 
research and participate in departmental 
research programs. Curriculum vitae should 
be sent to: Dr. Ronald L. Klein, Professor and 
Chairman, Department of Electrical and 
Computer Engineering, West Virginia Univer¬ 
sity, P.O. Box 6101, Morgantown, WV 
26506-6101. Applications will be received 
and considered immediately and the search 
will continue until all available positions are 
filled. West Virginia University is an affirmative 
action/equal opportunity employer m/f. 
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NAVAL POSTGRADUATE SCHOOL 
Computer Science Chairperson 

The Naval Postgraduate School invites ap¬ 
plications and nominations for the position of 
Chairperson of the Computer Science 
Department. We are seeking an individual 
who can provide leadership in both teaching 
and research to a strong and growing pro¬ 
gram. This person must have a Ph.D. in 
Computer Science or a closely related area 
and a distinguished record of research and 
publication as well as demonstrated adminis¬ 
trative capability. 

The Department offers M.S. and Ph.D. 
degrees in Computer Science. Currently, 110 
students are enrolled in the M.S. program and 
five in the Ph.D. program. No undergraduate 
degrees are offered. Students are military of¬ 
ficers or civilian employees of the Department 
of Defense and are fully supported by their 
sponsoring organization during their graduate 

The faculty currently consists of thirteen full¬ 
time civilian faculty, five military faculty, and 
several adjunct faculty. Additional positions 
are open in all areas. Departmental facilities 
(supported by eight full-time computer profes¬ 
sionals) consist of six instructional and re¬ 
search laboratories including the Database 
Systems Laboratory, the Graphics and Video 
Laboratory, the Software Engineering Labo¬ 
ratory, the Microcomputer Systems Labora¬ 
tory, the Artificial Intelligence Laboratory, and 
the Computer Science Academic Laboratory. 
In these laboratories are state-of-the-art com¬ 
puting equipment including a VAX 780, a 
VAX 785, LISP machines, high-performance 
graphics workstations, bit mapped graphics 
workstations, and multi-microprocessor 
systems. 

Located on Monterey Bay, the areas of 
Monterey, Pebble Beach, and Carmel pro¬ 
vide a pleasant Northern California coastal 
climate and easy access to Silicon Valley com¬ 
panies and universities. 

Please send a detailed resume and letters of 
reference to: 

Chair Search Committee 
Computer Science Department (Code 52) 
Naval Postgraduate School 
Monterey, CA 93943 
Tel. No. (408) 646-2449 

AN EQUAL OPPORTUNITY/AFFIRMA¬ 
TIVE ACTION EMPLOYER. 


U.S. NAVAL ACADEMY 
Tenure-Track Faculty Position 
Computer Science 

Possession of earned Ph D. in computer 
Science or related field is required. Initial ap¬ 
pointment is normally three years—now 
open. Primary responsibility will be teaching 
Computer Science courses. Salary commen¬ 
surate with overall experience. Address in¬ 
quiries to: Chairman Computer Science 
Department, United States Naval Academy 
Annapolis, MD 21402. Deadline for receipt of 
applications is 30 November 1988. Applica¬ 
tions will be considered until the position is 
filled. An Equal Opportunity/Affirmative Ac¬ 
tion Employer. 


UNIVERSITY OF FLORIDA 

Computer & Information Sciences 
Department 

Applications are invited for visiting and 
tenure-track positions at all levels. Applicants 
must have strong research capability in one of 
the specialized areas and be able to teach a 
variety of courses in Computer and Informa¬ 
tion Sciences. Areas of special emphasis in¬ 
clude artificial intelligence, computer vision, 
database management systems, distributed 
computing systems, parallel processing and 
software engineering. Positions are available 
for Spring 1989 as well as the 1989-90 aca¬ 
demic year. Each applicant must have a doc¬ 
toral degree in computer science or a related 
area or will complete the degree before the 
start of the faculty appointment. 

Qualified applicants should send their 
resumes, and the names and addresses of at 
least three references to: Dr. Stephen S. 
Yau, Chairman, Computer and Information 
Sciences Department, 301 CSE, University 
of Florida, Gainesville, Florida 32611; Tele¬ 
phone Number: 904/335-8000; e-mail ad¬ 
dress: yau@ufl.edu. 

Closing date: October 17, 1988 or until 
positions are filled. University of Florida is an 
Equal Opportunity/Affirmative Action Em¬ 
ployer, and the search will be in compliance 
with Florida’s “government in the Sunshine 


UNIVERSITY OF NORTH DAKOTA 
Center for Aerospace Sciences 

Associate Dean 

The University of North Dakota invites ap¬ 
plications for an anticipated opening as 
Associate Dean at the Center for Aerospace 
Sciences. The Center for Aerospace Sciences 
is the second largest degree granting college 
within the University and includes the Depart¬ 
ments of Aviation, Atmospheric Sciences, 
Computer Science, and Space Studies as well 
as the Divisions of Flight Operations and 
Computer Services. This position is a vital part 
of the Dean’s office and has primary responsi¬ 
bility for the academic leadership to the facul¬ 
ty, staff, and students of the college in all 
aspects of research, teaching, and service. 
The Associate Dean also contributes to the 
maintaining of effective relationships with state 
and federal agencies. Candidates must have 
scholarly accomplishment and breadth of in¬ 
terests, commitment to high academic stan¬ 
dards, and proven administrative ability. Aca¬ 
demic qualifications, including earned doc¬ 
torate in an appropriate field, should meet 
customary expectations for appointment as 
full professor. This is a tenure-eligible 12 
month appointment, with an anticipated start¬ 
ing date of September 1, 1988. Salary is com¬ 
petitive and commensurate with experience 
and qualifications. Send letter of application 
and resume to the Chair, Associate Dean 
Search Committee, Center for Aerospace 
Sciences, Box 8216, University Station, 
Grand Forks, ND 58202. The University of 
North Dakota is an Affirmative Action/Equal 
Opportunity Employer. 


COLORADO STATE UNIVERSITY 

The Computer Science Department solicits 
applications for tenure-track and visiting facul¬ 
ty positions at all levels (subject to funding). 
Candidates for assistant professor need a PhD 
in computer science or computer engineering 
(at time of appointment) with promise for ex¬ 
cellence in research and teaching; applicants 
for senior ranks must possess distinguished 
research records. We seek mainstream com¬ 
puter scientists in areas including architecture, 
artificial intelligence, graphics, languages and 
compilers, networks, software systems and 
engineering, and theory. In all areas we en¬ 
courage applicants with interests in parallel 
computing, broadly defined: concurrent, dis¬ 
tributed, vector, or systolic computing soft¬ 
ware, architectures, or applications. Salary is 
commensurate with rank and experience. 
New and visiting faculty will enjoy duties 
especially conducive to productive research. 

The Department offers BS, MS, and PhD 
degrees. We have excellent cooperative 
research relations with industrial and govern¬ 
ment laboratories, and their people form a 
significant portion of our graduate student 
population. We operate numerous multi-user 
systems (HP, DEC, Sequent, ATT) and 
many workstations (Sun, Apple, ATT), all 
networked. University operations include a 
CYBER 205 vector supercomputer. Depart¬ 
ment personnel work in a pleasant, smoke- 
free environment. 

Fort Collins is a growing community of 
89,000 located along the foothills of the 
Rocky Mountains, 60 miles north of Denver. 
The climate is moderate—about 15 inches of 
precipitation and 290 days of sunshine per 
year. There are many cultural opportunities 
and year-round outdoor activities. 

Send your curriculum vitae and names of at 
least three professional references to: Dr. R. 
R. Oldehoeft, Search Committee, Computer 
Science Department, Colorado State Univer¬ 
sity, Fort Collins, CO 80523. Applications for 
January 1989 will be considered October 15, 
1988. Applications for August, 1989 will be 
considered April 1, 1989. In each case the 
search will be extended if suitable candidates 
are not found. 

Colorado State University is an EEO/AA 
employer. EO Office: 314 Student Services 
Building. 


COMPUTER SYSTEMS ANALYST 

Min. 3 yrs. experience with BS degree 
either computer or business related field with 
computer background. Will assist our firm in 
the designing of our computer software prod¬ 
ucts to meet the tailored needs of our in¬ 
dividual clients. Will consult with clients to 
ascertain what type of data to be used, 
methods of collecting additional data, study¬ 
ing verbal description, physical models in 
order that the computers can be made to ser¬ 
vice our customer needs. Salary $37,800 per 
year. Send resume to: Micro Trends Interna¬ 
tional, 243 E. Colorado Blvd., Pasadena, CA 
91101. Attn: Riaz Khan, President. 
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CONFERENCES 


Editor: Edmund L. Gallizzi, Computer Science Dept., Eckerd College, St. Petersburg, FL 33733; (813) 864-8272; Compmail, e.gallizzi 


Conference keynoter foresees important technological developments 



ACM President Paul Abrahams (left photo) was presented a framed copy of the sil¬ 
ver anniversary commemorative poster during a special event June 14 celebrating 
the first quarter century of the Design Automation Conference. Computer Society 
President Ed Parrish (right), who also received one of the framed posters, wel¬ 
comed and commended those in the audience who worked toward the success of 
the conference series. Dennis Shaklee (not shown), 1988 general chair, made the 
presentations to Abrahams and Parrish. 


Chuck Governale, Assistant Editor 

Both silicon and gallium arsenide use 
will continue on upward curves, but sili¬ 
con will remain the “workhorse of the 
industry,” AT&T Bell Laboratories 
President Ian Ross predicted June 13 
when he keynoted the 25th Design 
Automation Conference. 

In an address he called “Future 
Developments in Information Technol¬ 
ogy,” Ross told his Anaheim, Califor¬ 
nia, audience that the high-tech 
challenges now facing industry should 
lead to a number of significant develop¬ 
ments in the next decade. Ross covered 
a lot of ground in his remarks, includ¬ 
ing photonics, optical computing, soft¬ 
ware, neural networking, and 
superconductivity. 

By the end of the century, he 
predicted, industry will produce its one 
billionth component chip of silicon. In 
the meantime, GaAs, while not over¬ 
taking silicon, will be used for “special 
applications because of its speed and 
ability to deal with light.” 

Still, said Ross, “We need to move 
towards all-photonic systems,” which 
have proven themselves in practical 



The volunteers who served as general chairs of the first 25 Design Automation Conferences, plus members of the 1988 DAC 
Executive Committee, were honored June 14 at a silver anniversary celebration in Anaheim. Nine of the general chairs were on 
hand (the years they served in that capacity are indicated below in parentheses). Pictured are (top row, from left) Daniel 
Schweikert, Don Thomas, Lawrence A. O’Neill (1987), Richard Newton, Charles E. Radke (1983), Tom Pennino, Patricia 
Lambert (1984), Thomas Minot, Richard Smith, William A. Dees, Robert J. Smith II (1981), Dennis Yinger, and (bottom, 
from left) Pat Pistilli (1964-66), David Hightower (1979), Robert Hitchcock (1975), Charles A. Shaw, Hillel Ofek (1985), and 
Dennis Shaklee (1988). 
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use. “Fiber is the medium of choice for 
moving information,” he said. “Our 
ability to move information any time, 
any place is not going to be limited by 
the media in which it will be moved.” 


“It’s only a matter of time before we 
will be able to select the most practical 
schemes” being developed, leading to a 
day when “we can begin to manipulate 
light with light,” the keynoter said. 


“Probably in the early 1990s, we will 
see systems switching light beams from 
one channel to another using optical in¬ 
puts,” he said. “I think we can be realisti¬ 
cally thinking—at least in our research 


Three presentations at special DAC session set tone for technical program 

Patrick McGeer, University of California, Berkeley 


High-level synthesis, mixed ana¬ 
log/digital synthesis and a “renais¬ 
sance of signal electronics” will 
dominate the next era of computer- 
aided design research, according to a 
leading European CAD researcher. 

Hugo De Man of IMEC and the 
Catholic University of Belgium made 
that prediction in an invited talk 
given at the special 25th anniversary 
session of the ACM/IEEE Design 
Automation Conference in Ana¬ 
heim, California, June 13. 

De Man’s presentation was one of 
three given during the special session 
that introduced the DAC technical 
program following the keynote 
address. Also sharing the podium 
were Ronald Rohrer of Carnegie 
Mellon University and Tsuneta Sudo 
of the Application Specific Design 
Technology Laboratory of NTT 
Corporation. 

Richard Newton of UC Berkeley 
served as program chair, and Dennis 
Shaklee of AT&T/ISL was general 
chair. 

Signal processing. “Commercial 
CAD systems address very well the 
issues of low- to medium- 
performance ‘glue’ logic and data 
processing,” said De Man, adding 
that the next generation of digital 
ICs will be high-performance signal 
processing applications. 

Signal processing is a term that 
refers to a broad class of electronic 
circuits, covering applications from 
robotic vision to Landsat imaging to 
compact disk and digital audio tape 
players. 

“In the 1990s, chip design will 
become a direct mapping of real¬ 
time behavior of systems into appli¬ 
cation-specific ICs containing some 
5 million transistors,” De Man said. 
Such chips will be highly suited for 
digital signal processing (DSP) appli¬ 
cations such as speech processing, 
image processing, video, and 
graphics, because “a very simple cal¬ 
culation will show you that the chips 
of the 90s, where one will be able to 
implement an algorithm directly into 


silicon rather than putting it in a 
general-purpose Von Neumann 
machine, will allow you to do several 
billion operations per second for a 
very cheap price, provided, of 
course, the design automation tools 
are present to do that.” 

The time to start thinking about 
those design automation tools is 
now, De Man said, describing a 
million-transistor, single-chip digital 
audio system. 

“It will contain a DSP system for 
input from the disk and error cor¬ 
rection, a mixed analog/digital 
server for motor speed and laser 
tracking, digital event emulation, 
digital stereo decoding and digital 
audio amplifiers, and 18-bit, very- 
high-performance digital-to-analog 
conversion. The last and smallest 
part is a small, digital micro¬ 
controller. On that chip, analog 
complexity will be exchanged for 
DSP speed and complexity by using 
over-sampled signa-delta techniques. 

“Using CAD tools now, we can 
synthesize the microcontroller in two 
days. Up to five years is spent in 
areas like digital signal processing 
and the analog interfaces. The CAD 
there ranges from problematic for 
the DSP to a total disaster if we’re 
talking about over-sampled conver¬ 
sion and feedback loops as well as a 
total disaster if we are looking at the 
high frequency ends, as there is vir¬ 
tually no system-level CAD avail¬ 
able,” De Man said. 

The CAD task in the analog/digi¬ 
tal area is particularly difficult, 
according to De Man, because cur¬ 
rent simulation and verification tech¬ 
niques cannot cope with the “time 
tyranny” that mixed analog/digital 
systems impose on simulators due to 
large simulation loads. 

“If you do over-sampling of an 
audio signal with 10 megahertz, or 
something like that, it means that for 
a few seconds of speech or images, 
you will need millions of samples to 
be simulated, and that was not what 
you were after anyway, because the 
specifications for these systems are 


expressed in the frequency domain.” 

One possible solution to this prob¬ 
lem, said the speaker, is the use of 
formal computer science verification 
techniques, possibly using functional 
specification languages and intelli¬ 
gent compilation techniques. 

Functional specification and func¬ 
tional programming languages such 
as FP and pure Lisp have long been 
favorites of program verification 
theorists, since it is relatively easy to 
prove correct programs written in a 
functional language. Their accep¬ 
tance in the software world, how¬ 
ever, has been impeded by the 
difficulty of writing efficient pro¬ 
grams in these languages or of com¬ 
piling them effectively for a broad 
class of machine. 

Another major problem in design¬ 
ing these circuits, according to De 
Man, is a lack of expertise in analog 
design: “The number of people who 
understand something other than 
ones and zeros is decreasing very 
rapidly and that’s alarming me.” 

One solution to this, he added, is 
to use silicon assemblers—programs 
that simply glue together previously 
designed circuit elements. These pro¬ 
grams will be much more complex 
than digital silicon assemblers due to 
the level of technology required. 

“I still think that one of the major 
problems in this area is to find the 
people who still understand the 
black art of analog design and the 
mathematics and computer science 
for all of this.” 

De Man further predicted the 
development of an integrated design 
and production system for fast turn¬ 
around of ASICs, interest in board- 
level partitioning, and the development 
of an “engineering environment”—a 
framework to manage the large col¬ 
lection of tools and data required for 
the massive CAD environment he 
sees in the 1990s. 

Frameworks are generic platforms 
for CAD tools; they combine the 
functions of database manager, 
browser, and user/tool interface 
specification. Broadly, a framework 
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labs—about optical computers before 
the end of the century.” 

Turning his focus to software, Ross 
said the productivity of the software 
developer has been nowhere near the 


productivity improvements in photonics 
or silicon, and that, he said, could pose 
a threat. 

“If we don’t get the solution to that 
problem, it’s possible that software 


capability will be the limiting factor in 
what can be done with all of this tech¬ 
nology,” the keynoter stated. 

Ross turned his attention to the area 
of neural networking, saying it has 


provides the environment within 
which users interact with a broad 
range of CAD tools from different 
suppliers, and within which the tools 
interact. 

Frameworks stressed. Frameworks 
were also emphasized in the address 
given by Rohrer of CMU. Rohrer, 
one of the original developers of the 
Spice simulation program, told the 
audience that CAD was entering a 
third generation of tools in which 
“software-only systems” on stan¬ 
dard software platforms would dom¬ 
inate the industry, and that a fourth 
generation, based on hardware 
accelerators, would take over in the 
1990s. 

The first generation lasted from 
1970 to 1982, Rohrer said. In this 
generation, he said, the CAD task 
was the generation of masks from 
geometric input, and the platform 
was proprietary: all the platform 
tasks were performed by the hard¬ 
ware manufacturer. 

The second generation, which is 
just ending, has been characterized 
by the generation of symbolic layout 
from schematic descriptions, and the 
platform was “bundled”—a hard¬ 
ware/software mix purchased from 
different manufacturers and packaged 
by original equipment manufacturers. 

In the third generation, “which is 
just now beginning,” Rohrer said, 
the task will be the generation of 
schematics, or netlists, from Boolean 
equations, and the platform will be a 
mix of lower-level CAD tools 
embedded in a software framework. 

In the fourth generation, which 
will dominate CAD in the early-to- 
mid 1990s, the CAD task will be the 
generation of Boolean equations 
from behavioral input. In this gener¬ 
ation, Rohrer sees hardware acceler¬ 
ation entering the platform. 

“We are at the cutting edge of 
technology and, if what we purport 
to be true is true, that is, if one can 
make a behavioral description and 
ask that it be compiled easily and 
effectively under silicon, I think that 
we’ll find hardware acceleration as a 
component of our own endeavor. 

“If we do what we say we can do, 
it will be cost-effective to provide 


that kind of capability and, more¬ 
over, it’ll be an excellent way to pro¬ 
tect our software. I’m not talking 
about things that give me 1,000X (a 
thousand times the speed); I’m talk¬ 
ing about things that enable you to 
sell something and not have it ripped 
off, and may give you 10X cost- 
effectiveness. ” 

Rohrer depicted the evolutionary 
stages of CAD as eras of increasing 
abstraction, where each generation 
of CAD tools addresses a higher 
level of abstraction and the platform 
becomes more and more generic, 
and where, at each level, a different 
customer is addressed. 

“The consequence of having 
ascended that hierarchy is that at 
each stage of the business we’ve 
managed to deal with a different 
designer. We’ve gone from circuit 
designer to logic designer, now to 
hardware designer, and ultimately to 
system designer. The common wis¬ 
dom, and it’s good for our business, 
is that there are more of the abstract 
designers.” 

One result of this is that, at each 
generation, more of the interface 
problems were solved by generic 
software and hardware. The early 
days of proprietary hardware com¬ 
panies were eventually displaced by 
the generic graphics workstation. 

The second generation’s bundled 
systems with proprietary user inter¬ 
face are on the verge of being dis¬ 
placed, Rohrer said. 

“I don’t think that user interface 
is any longer our project. That 
doesn’t mean that there isn’t any 
work that needs to be done in our 
business at the user interface. It’s 
simply that Unix, C, X-Windows, 
etc., is there, it’s accepted. The new 
user community is saying, ‘Look, 
we’ve standardized on Y box 
because it gives us the price/perfor¬ 
mance we want and your tools had 
better run on that box or we’re not 
interested in dealing with you’.” 

In this generation, framework- 
design data management systems— 
will be the dominant platform issue, 
said Rohrer, cautioning that “we’re 
not as unique as we think we are. As 
much as we might talk about inor¬ 
dinate demands on data manage¬ 


ment, I assure you that automobiles 
and airplanes, bridges and buildings 
all have inordinate demands on data 
management. Even though we have 
to get into this (framework) business 
to satisfy our inherent needs, invari¬ 
ably because there’s a bigger market¬ 
place out there and a larger commun¬ 
ity, someone will come along to pro¬ 
vide a generic solution to our prob¬ 
lem as has happened in the past. 

“In the early days, the purveyors 
of electronic design automation sys¬ 
tems had to do it all. As we go for¬ 
ward, I think that we will find that 
our business will really become 
focused on the inherent applications. ” 

Finally, Rohrer noted that each 
generation further specialized the 
class of circuits for which design 
automation was supported. Analog 
design, in particular, has never been 
supported by the CAD tool com¬ 
munity. 

“We’ve left behind the analog 
designer with his 17.2 degree angles, 
his bipolar devices, etc. Part of that 
has been the recalcitrance of that 
community to give up anything, and 
one must sacrifice some generality to 
go up. The digital designer has been 
much more amenable to constraint, 
and that has helped a great deal. ” 

Nevertheless, Rohrer said, analog 
design must be supported. “As chips 
in systems become more and more 
complex, inevitably some analog 
creeps into the system. 

“Another trend is that, as feature 
sizes become smaller and smaller, 
what we want to be a digital system 
becomes analog in its character; as 
we face an era in which analog 
design is inevitable, we really have to 
go clear back to the bottom (design 
level) and look at all we’ve given up 
and pick back up a great deal of it.” 

Japanese activities. In his talk, 
Sudo of NTT reviewed design auto¬ 
mation activities in Japan for the last 
25 years, concentrating specifically 
on tools to support hierarchical design 
and on rule-based logic synthesis. 

Sudo emphasized current stan¬ 
dardization efforts in Japan and sug¬ 
gested that standardization would 
become increasingly important for 
clear communication among compa¬ 
nies and universities. 
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“some interesting possibilities.” 

“Way in the back of our thinking is 
the possibility that maybe these are 
machines that can learn. If you can get 
a machine that can learn, then maybe it 
can be creating some of its own soft¬ 
ware the way clearly all of us did in our 
formative years,” he said. 

On superconductivity, Ross said, 

“It’s quite possible that the most useful 
outcome of the exciting breakthrough 
in superconductivity is that we will learn 
some new physics. That may take us in 
directions that could include supercon¬ 
ductivity at higher temperatures or a 
number of other things.” 


“We do have a happy marriage of a 
rapid change in customer needs for the 
movement and management of infor¬ 
mation and, at the same time, a very 
dramatic continuing improvement in 
the technologies that can help those 
things come to pass.” 

Award presentations. The confer¬ 
ence’s cosponsors, the Computer Soci¬ 
ety’s Technical Committee on Design 
Automation and the ACM’s Special 
Interest Group on Design Automation, 
presented a number of awards just prior 
to the Ross plenary-session address. 

Heading the list were joint ACM/CS 


Silver Anniversary Awards to the 
general chairs of the first 25 DACs, 
from Pat Pistilli, who chaired the first 
three events in 1964-66, to Dennis Shak- 
lee, who chaired this year’s session. 
Pistilli also received the DAC Executive 
Committee Award for exceptionally 
dedicated and meritorious service over 
the 25-year period. 

The society presented Outstanding 
Contribution Certificates to Vishwani 
Agrawal, Erich Marschner, and Larry 
Saunders; Meritorious Service Certifi¬ 
cates to J. Daniel Nash and Marie R. 
Pistilli; and Certificates of Appreciation 
to Moe Shahdad and Wing Toy. 


Distributed Computing Systems Conference features two keynote talks 


Marvin Theimer, IBM Almaden Research Center 


Mack Alford of A scent Logic and 
Stephen Woltt ot the NatiewaPScience 
Foundation were the keynote speakers 
at the eighth International Conference 
on Distributed Computing Systems, 
held June 13 to 17 in San Jose, California. 

Carl Davis of the University of Ala¬ 
bama at Huntsville was the general 
chair, and Walter Kohler of the Univer¬ 
sity of Massachusetts was program 
chair. The event was sponsored by the 
Computer Society and the Technical 
Committee on Distributed Processing. 

CASE DDP requirements. Com¬ 
puter-aided software engineering for 
distributed data processing was the 
focus of Alford’s talk, entitled “The 
Requirements for DDP CASE.” 

He identified the principal require¬ 
ments for CASE as 

• supporting the generation of the 
paper needs of a project, 

• using a systematic approach, and 

• helping with mundane tasks 
through automation. 

Distributed data processing require¬ 
ments implied the need for more 
resources and more reliability. Thus, 
DDP CASE faces all the problems of 
CASE plus all the problems of DDP. 

The issue of “translation” versus 
“decomposition” was one of the key 
problems Alford focused on during his 
talk. He contended that most errors in 
software projects are caused by incor¬ 
rect translation between different 
representations of a problem. 

CASE systems should aim at 
minimizing the number of representa¬ 
tions used for a problem and, instead, 
focus on supporting intelligent decom¬ 


position of problems into their constitu¬ 
ent pieces. 

NSFnet status, plans. In his talk, 
Wolff discussed the status of the 
NSFnet and some of its future plans. 

He described the goal of this national 
network as “interconnecting scientists 
and scholars.” 

The network is a hierarchically struc¬ 
tured datagram network that uses the 
transmission-control protocol/Internet 
protocol (TCP/IP) communication pro¬ 
tocol suite. The network consists of a 
backbone that interconnects “mid¬ 
level” networks and campus networks. 

Mid-level networks can be regional 
networks, supercomputer consortium 
networks, or community-of-interest net¬ 
works, such as CSnet or Bitnet. 

Currently, the backbone network 
uses 56 kilobit-per-second links, but 
these links will soon be replaced by new 
1.5-megabit-per-second links. Wolff 
foresees the network expanding rapidly 
in the future, with 45-Mbps links soon 
replacing the 1.5-Mbps links and ever- 
increasing numbers of connections to 
other networks being established. 

For example, many new connections 
will be made to other countries. 

Load balancing was one of the domi¬ 
nant themes throughout the conference. 
Several of the 66 papers presented in 
two parallel tracks discussed the theo¬ 
retical issues and practical experience of 
load balancing. 

Panel discussion. The first evening of 
the conference was devoted to a panel 
session on “Critical Issues in Dis¬ 
tributed Real-Time Systems.” The 
panelists were Walter Heimerdinger of 
Honeywell, A1 Mok of the University of 


Texas at Austin, Fred Schneider of Cor¬ 
nell University, Lui Sha of Carnegie 
Mellon University, John Stankovic of 
the University of Massachusetts at 
Amherst, Earl Swartzlander of TRW, 
and Andre van Tilborg of the Office of 
Naval Research. Horst Wedde of 
Wayne State University served as 
moderator. 

Three issues dominated much of the 
panel’s discussion. 

Schneider opened the session by not¬ 
ing that a principal problem with the 
specification of real-time systems is that 
of “time.” He argued that time should 
really be treated as an “implementation 
detail” and that the correct way to 
think about real-time systems is to 
view them as synchronization problems 
between asynchronous processes, some 
of which are implemented by nature. 

Everyone agreed that many problems 
could be treated this way, but most of 
the panelists felt that time could not be 
completely factored out of a system’s 
specification. 

A second topic concerned the fact 
that real-time systems requirements fre¬ 
quently conflict with assumptions that 
most operating systems make, such as 
fair scheduling. 

Scheduling also came into play when 
discussing the problem of how to deal 
with the time required to compute the 
state of a real-time system. 

The third topic that received extended 
mention was the need for a more formal 
approach to real-time systems. Several 
of the panelists pointed out that the cur¬ 
rent state of the art was ad-hoc in 
nature and that more work needs to be 
done on formal modeling, analysis, and 
specification of real-time systems. 
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A. Blanton Godfrey will be the keynote 
speaker at the 1988 International Test 
Conference. 


Godfrey to address 
Test Conference 

A. Blanton Godfrey, chairman and 
chief executive officer of the Juran 
Institute of Wilton, Connecticut, will 
keynote the 1988 International Test 
Conference September 12-14 in Wash¬ 
ington, DC. The event is sponsored by 
the Computer Society. 

Godfrey will speak on “Managing 
Quality—Today’s Opportunities, 
Tomorrow’s Challenges.” He says that 
quality is not an issue solely for manu¬ 
facturing but involves every function 
within a company. 

Don Denburg of AT&T Bell Labora¬ 
tories, program chair of this year’s ITC, 
said the 1988 conference theme, “New 
Frontiers in Testing,” reflects the elec¬ 
tronics industry’s concerns about the 
quality and yield of testing devices. 

“More complex and faster devices 
and assemblies are providing new 
opportunities and challenges for the 
electronics industry,” Denburg said. 
“The testing community is challenged 
to provide innovative and cost-effective 
techniques in testing.” 

Denburg said that the impact of the 
new devices will be especially evident in 
the technical paper sessions that look at 
electro-optical techniques in 1.2-gigabit- 
per-second device test sets; general pur¬ 
pose, high pin-count, 500-megahertz 
test sets; and membrane probes. 

Many of the papers will discuss vari¬ 
ous aspects of built-in self-test, which 
has been proposed as the ultimate solu¬ 
tion to the testing of the new, complex, 
high-speed devices. 


August 1988 


S Joint Fifth Symposium and Fifth Inter- 
" national Conference on Logic Pro¬ 
gramming (Assoc, for Logic Programming), 
Aug. 15-19, Seattle. Contact Kenneth A. 
Bowen, Logic Programming Research 
Group, School of Computer and Informa- 
n Science, 313 Link Hall, Syracuse Uni¬ 
versity, Syracuse, NY 13210, phone (315) 
423-2466 or 67. 

ICPP 17, 17th International Conference on 
Parallel Processing, Aug. 15-19, St. Charles, 
111. Contact David H. Bailey, MS 258-5, 
NASA Ames Research Center, Moffett 
Field, CA 94035; Howard E. Sturgis, Xerox 
Corp., Palo Alto Research Center, 3333 
Coyote Hill Rd., Palo Alto, CA 94304; or 
Faye A. Briggs, Sun Microsystems, 2550 
Garcia Ave., Mountain View, CA 94043. 

DIAC 88, Directions and Implications of 
Advanced Computing Symposium (CPSR), 
Aug. 21, St. Paul, Minn. Contact Doug 
Schuler, Computer Professionals for Social 
Responsibility, PO Box 717, Palo Alto, CA 
94301, phone (206) 865-3226. 

ii Crypto 88 (IACR), Aug. 21-25, Santa 
y Barbara, Calif. Contact Harold Fred- 
ricksen, Mathematics Dept., Code 53Fs, 
Naval Postgraduate School, Monterey, CA 
93943, phone (408) 646-2206. 

AAAI 88, Seventh National Conference on 
Artificial Intelligence (AAAI), Aug. 21-26, 

St. Paul, Minn. Contact American Assoc, 
for Artificial Intelligence, 445 Burgess Dr., 
Menlo Park, CA 94025, phone (415) 
328-3123. 


CAD/CAM Technology Transfer to Latin 
America Conference (IFIP), Aug. 22-26, 

Mexico City. Contact G. Leon Lastra, Insti¬ 
tute de Investigaciones Electricas, Apdo. 
Postal 5-849, 11590 Mexico, D.F., phone 52 
(73) 129-632. 

Coling 88, 12th International Conference on 
Computational Linguistics, Aug. 22-27, 

Budapest, Hungary. Contact Coling 88 
Secretariat, Mtesz Congress Bureau, H-1055 
Budapest, Kossuth ter. 6-8, Hungary. 

LFA 88, Sixth IEEE Workshop on 
^§7 Languages for Automation, Aug. 

29-31, College Park, Md. Contact Panos A. 
Ligomenides, Cybernetics Research Labora¬ 
tory, Electrical Engineering Dept., Univer¬ 
sity of Maryland, College Park, MD 20742, 
phone (301)454-6842. 

International Forum on Increasing Manage¬ 
ment Productivity with Intelligent Systems, 
Aug. 29-31, Snowmass-Aspen, Colo. Con¬ 
tact Center for Applied Artificial Intelli¬ 
gence, College of Business and 
Administration, University of Colorado, 
Campus Box 419, Boulder, CO 80309, phone 
(303) 492-8229. 

14th International Conference on Very 
*5*7 Large Databases (VLDB Endowment), 
Aug. 29-Sept. 1, Los Angeles. Contact Jack 
E. Shemer, Teradata Corp., 12945 Jefferson 
Blvd., Los Angeles, CA 90066, phone (213) 
827-8777. 

EuroMicro 88, 14th Symposium on Micro¬ 
processing and Microprogramming, Aug. 
29-Sept. 1, Zurich. Contact EuroMicro 88, 
PO Box 545, 7500 AM Enschede, The 
Netherlands, phone 31 (53) 33-87-99. 


Conferences that the Computer Society sponsors or participates it 
^*7 by the Computer Society logo; additional conference sponsors are 
theses. Other conferences of interest to our readers are also included. 


i are indicated 
listed in paren- 


For inclusion in Call for Papers or Calendar, submit information six weeks before the 
month of publication (i.e., for the October 1988 issue, send information for receipt by 
Aug. 15, 1988) to Calendar Editor, Computer, 10662 Los Vaqueros Cir., Los 
Alamitos, CA 90720. 
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International Conference on Computer Pro¬ 
cessing of Chinese and Oriental Languages, 
Aug. 29-Sept. 1, Toronto, Canada. Contact 
C.N. Liu, IBM T.J. Watson Research Cen¬ 
ter, PO Box 704, Yorktown Heights, NY 
10598, phone (914)789-7531. 

ICO Topical Meeting on Optical Com- 
99 puling, Aug. 30-Sept. 2, Orsay, 

France. Contact S. Lowenthal, Insitut D’Up- 
tique, BP 43, 91406 Orsay Cedex, France. 


September 1988 

International Neural Network Society 
99 Conference, Sept. 6-10, Boston. Con¬ 
tact Mark Kon, Dept, of Mathematics, Bos¬ 
ton University, 111 Cummington St., 

Boston, MA 02115, phone (617) 353-2762; or 
INNS Conference, J.R. Schuman Associ¬ 
ates, PO Box 125, 316 Washington St., 
Wellesley, M A 02181, phone (617) 237-7931. 

1988 International Test Conference, 

Sept. 12-14, Washington, DC. Contact 
Doris Thomas, ITC, PO Box 264, Mt. Free¬ 
dom, NJ 07970, phone (201) 895-5260. 

Mapping and Geographic Information Sys¬ 
tems 88 (NCGA), Sept. 12-15, Orlando, Fla. 
Contact National Computer Graphics 
Assoc., 2722 Merrilee Dr., Suite 200, Fair¬ 
fax, V A 22031. 

Eurographics 88, Ninth European Assoc, for 
Computer Graphics Conference (INRIA), 
Sept. 12-16, Nice, France. Contact INRIA, 
Service des Relations Exterieures, Domaine 
de Voluceau, BP 105, 78153 Le Chesnay 
Cedex, France, phone 33 (1) 39-63-55-01. 

© Workshop on Future Trends of Dis¬ 
tributed Computing Systems in the 
1990s, Sept. 14-16, Hong Kong. Contact 
Tien Chi Chen, United College, Chinese Uni¬ 
versity of Hong Kong, Shatin, N.T., Hong 
Kong, phone 852 (5) 695-2576. 

Fourth International Conference of 
99 Modeling Techniques and Tools for 
Computer Performance Evaluation (U1B, 
ATI), Sept. 15-17, Palma de Mallorca, 

Spain. Contact Ramon Puigjaner, U1B, 
Miguel dels Sants Oliver 2, 07012 Palma de 
Mallorca, Spain, phone 34 (71) 72-57-06. 

IEEE Artificial Neural Networks Con- 
'5*5' ference. Sept. 18-21, Reston, Va. Con¬ 
tact Kamal Karma, 823 Flegler Rd., 
Gaithersburg, MD 20879, phone (301) 
984-7657. 

Fourth International Symposium on Biologi¬ 
cal and Artificial Intelligence Systems, Sept. 
18-22, Trento, Italy. Contact Alberta Mar¬ 
tino, IBM Corp., Dept. 48B/428, Neighbor¬ 
hood Rd., Kingston, NY 12401, phone (914) 
385-4964. 


Sixth Software Quality Conference (Pacific 
Northwest Software Quality Conference 
Committee), Sept. 19-20, Portland, Ore. 
Contact Mary Lawrence, Lawrence & Craig, 
320 SW Stark, Rm. 411, Portland, OR 
97204, phone (503) 222-2606. 

Conference on Computerized Assistance 
During System Life Cycle (IFIP), Sept. 

19-22, London. Contact International Feder¬ 
ation for Information Processing, 3 rue de 
Marche, CH-1204, Geneva, Switzerland. 

Workshop and Symposium on Formal Tech¬ 
niques in Real-time and Fault-tolerant Sys¬ 
tems, Sept. 20-23, Coventry, England. 
Contact M. Joseph, Dept, of Computer 
Science, University of Warwick, Coventry, 
CV4 7AL, UK. 

First International Workshop on 
Transaction Machine Architecture, 
Sept. 25-28, Lake Arrowhead, Calif. Con¬ 
tact Martin Freeman, Signetics Corp., 811 E. 
Arques Ave., Sunnyvale, CA 94086, phone 
(408)991-3591. 

OOPSLA 88 (ACM), Sept. 25-30, San 
Diego, Calif. Contact Barbara Noparstak, 
Digitalk, Inc., 9841 Airport Blvd, Los 
Angeles, CA 90045, phone (213) 645-1082. 

ZIX Computational Intelligence 88 (ACM), 
*9? Sept. 26-30, Milan, Italy. Contact 
Giorgio Valle, Universita di Milano, Dip. di 
Sciencze dell’Informazione, Via Moretto 9, 
20133 Milano, Italy, phone 39 (2) 27-72-228. 

Second International Workshop on 
9? Object-Oriented Programming Data¬ 
base Systems (GI, FZ1, ACM), Sept. 27-30, 
Bad Muensteram Stein-Ebernburg, Ger¬ 
many. Contact Alex Buchmann, CCA, 4 
Cambridge Center, Cambridge, MA 02142, 
phone (617)492-8860. 

26th Allerton Conference on Communica¬ 
tion, Control, and Computing, Sept. 28-30, 

Monticello, Ill. Contact Allerton Confer¬ 
ence, c/o Mark W. Spong, Coordinated 
Science Laboratory, University of Illinois at 
Urbana-Champaign, 1101 W. Springfield 
Ave., Urbana, IL 61801, phone (217) 
333-4281. 


October 1988 

1CCD 88, IEEE International Confer- 
9? ence on Computer Design, Oct. 2-6, 

Rye Brook, N.Y. Contact Prathima Agra- 
wal, ICCD 88, AT&T Bell Laboratories, 600 
Mountain Ave., Rm. 3D-480, Murray Hill, 
NJ 07974, phone (201) 582-6943. 

EWSL 88, Third European Working Session 
on Learning, Oct. 3-5, Glasgow, Scotland. 
Contact Derek Sleeman, Dept, of Comput¬ 
ing Science, University of Aberdeen, Aber¬ 
deen AB9 2UB, Scotland, UK, phone 44 
(224) 27-22-88. 


Compsac 88, 12th International Com- 
99 puter Software and Applications Con¬ 
ference, Oct. 3-7, Chicago. Contact Wing N. 
Toy, Compsac 88, AT&T Bell Laboratories, 
Rm. 1Z-306, 200 Park Plaza, Naperville, IL 
60566, phone (312) 416-4046. 

1988 International Display Research Confer¬ 
ence (IEEE, SID), Oct. 4-6, San Diego, 

Calif. Contact Palisades Institute for 
Research Services, Attn. IDRC, 201 Varick 
St., New York, NY 10014, phone (212) 
620-3388. 

Northcon 88 (IEEE, ERA, EMA), Oct. 4-6, 

Seattle. Contact Electronic Conventions 
Management, 8110 Airport Blvd., Los 
Angeles, CA 90045-3194, phone (213) 
772-2965. 

International Workshop on Defect and 
99 Fault Tolerance in VLSI Systems, Oct. 
6-7, Springfield, Mass. Contact Israel Koren, 
Dept, of Electrical and Computer Engineer¬ 
ing, University of Massachusetts, Amherst, 
MA 01003, phone (413) 545-2643. 

NCGA CAD/CAM 88, Oct. 9-12, Boston. 
Contact NCGA CAD/CAM 88, National 
Computer Graphics Assoc., 2722 Merrilee 
Dr., Suite 200, Fairfax, VA 22031. 

ZSN ICCL 88, International Conference on 
99 Computer Languages, Oct. 9-13, 

Miami Beach, Fla. Contact Pei Hsia, Com¬ 
puter Science Engineering Dept., University 
of Texas, 2100 Oak Bluff Dr., Arlington, 

TX 76019, phone (817) 273-3610. 

Z2N Seventh Symposium on Reliable Dis- 
99 tributed Systems, Oct. 10-12, 

Columbus, Ohio. Contact David Cohen, 
Tekuekron Infoswitch, 1784 Firman Dr., 
Richardson, TX 75081; or Ming T. Liu, 
Dept, of Computer and Information 
Science, Ohio State University, 2036 Neil 
Ave., Columbus, OH 43210-1277, phone 

(614) 292-1837. 

Z2N 1988 IEEE Workshop on Visual Lan- 
99 guages, Oct. 10-12, Pittsburgh. Con¬ 
tact A.T. Berztiss, Dept, of Computer 
Science, University of Pittsburgh, Pitts¬ 
burgh, PA 15260. 

13th Conference on Local Computer 
'58' Networks, Oct. 10-12, Minneapolis, 
Minn. Contact Ron Rutledge, Martin 
Marietta Energy Systems, Bldg. 4500N, 
MS-271, PO Box X, Oak Ridge National 
Laboratory, Oak Ridge, TN 37831, phone 

(615) 576-7643. 

Z2N Frontiers 88, Second Symposium on 
99 Frontiers of Massively Parallel 
Computation, Oct. 10-12, Fairfax, Va. Con¬ 
tact James R. Fischer, Frontiers 88 Sympo¬ 
sium, Code 635, NASA Goddard Space 
Flight Center, Greenbelt, MD 20771, phone 
(301)286-3464. 

International Workshop on Computer 
Vision (IAPR), Oct. 12-14, Tokyo. Contact 
Mikio Takagi, Institute of Industrial 
Science, University of Tokyo, 7-22-1, Rop- 
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pongi, Minato-ku, Tokyo 106, Japan, phone 
81 (3)479-0289. 

ACM SIGGraph Symposium on User Inter¬ 
face Software, Oct. 17-19, Banff, Canada. 
Contact John Sibert, Dept, of Electrical 
Engineering and Computer Science, George 
Washington University, Washington, DC 
20052, phone (202) 994-4953. 

Fourth International Conference on Satellite 
Systems for Mobile Communications and 
Navigation (IEE), Oct. 17-19, London. Con¬ 
tact Conference Services Dept., Institution 
of Electrical Engineers, Savoy PL, London 
WC2R 0BL, UK, phone 44 (1) 240-1871. 

Third International Symposium on Knowl¬ 
edge Engineering (AAAI), Oct. 17-21, 

Madrid, Spain. Contact Jose R. Chelala, 
Third International Symposium on Knowl¬ 
edge Engineering, Alvarez de Baena, 3-2, 
28006 Madrid, Spain. 


Fourth Software Engineering Conference 
and Exhibition (AFCET), Oct. 18-21, Paris. 
Contact CGL4, 156 blvd. Pereire, 75017 
Paris, France. 


1988 Concom, Advances in Communications 
and Control Systems, Oct. 19-20, Baton 
Rouge, La. Contact Morteza Naraghi-Pour, 
Dept, of Electrical and Computer Engineer¬ 
ing, Louisiana State University, Baton 
Rouge, LA 70803, phone (504) 388-5551. 


29th Foundations of Computer Science 
'8? (FOCS), Oct. 24-26, White Plains, 

N.Y. Contact Christos Papadimitrou, De¬ 
partment of Computer Science and Engineer¬ 
ing, University of California at San Diego, 

La Jolla, CA 92043, phone (619) 534-2086. 

Z2N CSM 88, Conference on Software 

Maintenance—1988, Oct. 24-27, Phoe¬ 
nix, Ariz. Contact Robert Arnold, Software 
Productivity Consortium, 1880 Campus 
Commons Dr. North, Reston, VA 22091, 
phone (703)391-1898. 


First International Symposium on Artificial 
Intelligence, Oct. 24-28, Monterrey N.L., 
Mexico. Contact Francisco J. Cantu, Insti- 
tuto Tecnologico de Monterrey, ITESM Sue. 
Correos “J”, Monterrey N.L., Mexico, 
64849, phone 52 (83) 59-59-43. 


Second International Software for 
Strategic Systems Conference, Oct. 
25-26, Huntsville, Ala. Contact Karen B. 
Mack, University of Alabama, Division of 
Continuing Education, Tom Bevill Center, 
Huntsville, AL 35899, phone (205) 895-6357. 


IECON 88 (IEEE), Oct. 25-27, Singapore. 
Contact V.K.L. Huang, AT&T Information 
Systems, Crawford Corners Rd., Holmdel, 
NJ 07733, phone (210) 949-0069. 

Systec 88, Second International Trade Fair 
for Computer-Integrated Manufacturing, 
Oct. 25-28, Munich, West Germany. Contact 
Munchener Messe- und Ausstellungsgesell- 


schaft mbH, Projektleitung Systec 88, Post- 
fach 12 10 09, D-8000 Munchen 12, West 
Germany, phone 49 (89) 51-070. 


Ninth IEEE Symposium on Mass Stor- 
^§7 age Systems, Oct. 30-Nov. 3, Mon¬ 
terey, Calif. Contact Patric Savage, Shell 
Development Co., PO Box 481, Houston, 
TX 77001, phone (713) 663-2384. 


ICCC 88, Ninth International Conference on 
Computer Communication (IEEE Israel Sec¬ 
tion), Oct. 30-Nov. 3, Tel Aviv, Israel. Con¬ 
tact J. Kella, Secretariat, PO Box 50006, Tel 
Aviv 61500, Israel, phone 972 (3) 654-571. 


22nd Asilomar Conference on Signals, 
Systems, and Computers (IEEE, Naval 
Postgraduate School), Oct. 31-Nov. 2, 

Pacific Grove, Calif. Contact Douglas 
Elliott, Rockwell International, 3370 Mira- 
loma Ave., Mail Stop BD07, Anaheim, CA 
92803-317, phone (714) 762-2340. 


ICCS 88, International Conference on Com¬ 
munication Systems (IEEE), Oct. 31-Nov. 3, 

Singapore. Contact ICCS 88, c/o Meeting 
Planners Pte Ltd., 100 Beach Rd., #33-04, 
Shaw Towers, Singapore 0718. 


November 1988 


1988 Workshop on VLSI Signal Processing, 
Nov. 2-4, Monterey, Calif. Contact Paulette 
Powell, Electronics Research Laboratory, 
University of California, Berkeley, CA 
94720, phone (415) 642-1566. 


Symposium on Computer Graphics Educa¬ 
tion, Nov. 4-5, Poughkeepsie, N.Y. Contact 
Deborah Coleman, West Coast University, 
440 Shatto PL, Los Angeles, CA 90020; or 
William J. Joel, Marist College, 82 North 
Rd., Poughkeepsie, NY 12601. 


12th Symposium on Computer Applications 
in Medical Care, Nov. 6-9, Washington, DC. 
Contact Office of Continuing Medical Edu¬ 
cation, George Washington University Medi¬ 
cal Center, 2300 K St. NW, Washington, DC 
20037, phone (202) 994-8928. 


^2^, ICCAD 88, IEEE International Con- 
ference on Computer-Aided Design 
(ACM) Nov. 7-10, Santa Clara, Calif. Con¬ 
tact A1 Jimenez, Mentor Graphics Corp., 
1940 Zanker Rd., San Jose, CA 95112, 
phone (408) 436-1500; or Pro CASE, 3130 
Dela Cruz Blvd., Suite 100, Santa Clara, CA 
95054, phone (408) 72,7-0714. 


Third Workshop on Knowledge Acquisition 
for Knowledge-Based Systems (AAAI), Nov. 
7-11, Banff, Canada. Contact John H. 
Boose, Advanced Technology Center, Boe¬ 
ing Computer Services, MS 7L-64, PO Box 
24346, Seattle, WA 98124, phone (206) 
865-3253. 


GOMAC 88, Government Microcircuit 
Applications Conference, Nov. 8-10, Las 

Vegas, Nev. Contact C. Edward Holland, 
Jr., Semiconductor Research Corp., 4501 
Alexander Dr., PO Box 12053, Research Tri¬ 
angle Park, NC 27709, phone (919) 

541-9400. 


1988 IEEE Nuclear Science Symposium and 
Symposium on Nuclear Power Systems, 
Nov. 9-11, Orlando, Fla. Contact E. Bar- 
sotti, Fermilab, MS 222, Box 500, Batavia, 
IL 60510, phone (312) 840-4061. 


Second International Symposium on 
Interoperable Information Systems 
(INTAP), Nov. 10-11, Tokyo. Contact 
Hideo Aiso, Dept, of Electrical Engineering, 
Keio University, 3-14-1, Hiyoshi, Kohoku- 
ku, Yokohama, Karagawa, 223 Japan, 
phone 81 (44)63-1141, ext. 3320. 


Ninth International Conference on Pattern 
Recognition (IAPR), Nov. 14-17, Rome. 
Contact M.J.B. Duff, Dept, of Physics and 
Astronomy, University College London, 
Gower St., London WC1E 6BT, England, 
UK, phone 44 (1) 380-7010; Herbert Free¬ 
man, CAIP Center, Rutgers University, Pis- 
cataway, NJ 08855-1390, phone (201) 
932-3443; or Stefano Levialdi, Dipartimento 
di Matematica, Universita di Roma, Piazzale 
Aldo Moro 2,1-00185 Roma, Italy, phone 39 
(6) 49-91-32-49 or 50. 

Z2^ Supercomputing 88 (ACM), Nov. 

14-18, Kissimmee, Fla. Contact George 
Michael, Lawrence Livermore National 
Laboratory, PO Box 808, L-306, Livermore, 
CA 94550, phone (415) 422-4239. 


Z2^ Seventh International Conference on 
^*7 Entity-Relationship Approach (ERI), 
Nov. 14-18, Rome. Contact Salvatore T. 
March, Management Sciences, University of 
Minnesota, 271 19th Ave. South, Min¬ 
neapolis, MN 55455, phone (612) 624-2017. 


Fourth Conference on Artificial Intelligence 
for Space Applications (NASA), Nov. 15-16, 

Huntsville, Ala. Contact Conference on 
Artificial Intelligence for Space Applica¬ 
tions, NASA/EB44, MSFC, AL 35812, 
phone (205) 544-5181. 


AIDA 88, Fourth Conference on Artificial 
Intelligence and Ada, Nov. 15-16, Washing¬ 
ton, DC. Contact Jorge Diaz-Herrera, Com¬ 
puter Science Dept., George Mason Uni¬ 
versity, 400 University Dr., Fairfax, VA 
22030, phone (703) 323-2713. 
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Sixth CIPS Edmonton Computer Confer¬ 
ence, Nov. 15-17, Edmonton, Canada. Con¬ 
tact U.M. Maydell, Dept, of Computing 
Science, University of Alberta, Edmonton, 
Alberta, T6G 2H1, Canada. 


Wescon 88 (IEEE), Nov. 15-17, Anaheim, 
Calif. Contact Wescon 88, c/o Electronic 
Conventions Management Educational 
Activities Dept., 8110 Airport Blvd., Los 
Angeles, CA 90045, phone (213) 772-2965. 


12th Western Educational Computing Con¬ 
ference (California Educational Computing 
Consortium), Nov. 17-18, San Diego, Calif. 
Contact Judah Rosenwald, Extended Educa¬ 
tion, NAD 153, San Francisco State Univer¬ 
sity, 1600 Holloway, San Francisco, CA 
94132, phone (415) 338-1212. 


Micro 21, Workshop on Micropro- 
7*7 gramming and Microarchitecture 
(ACM), Nov. 28-Dec. 1, San Diego, Calif. 
Contact Wen-Mei Hwu, Coordinated 
Science Laboratory, University of Illinois at 
Urbana-Champaign, 1101 W. Springfield 
Ave., Urbana, IL 61801, phone (217) 
244-8270. 


KGCS 88, International Conference on 
7*7 Fifth Generation Computer Systems 
(1PSJ), Nov. 28-Dec. 2, Tokyo. Contact 
Hideo Aiso, Dept, of Electrical Engineering, 
Keio University, 3-14-1, Hiyoshi, Kohoku- 
ku, Yokohama, Karagawa, 223 Japan, 
phone 81 (44) 63-1141, ext. 3320. 


December 1988 


IEEE Globecom 88, Dec. 1-2, Hollywood, 
Fla. Contact Dennis J. Sassa, Bell Commu¬ 
nications Research, NVC 2Z-129, 331 New¬ 
man Springs Rd„ Red Bank, NJ 07701-7020, 
phone (201) 446-6787. 


EuroComm 88, Second International Exhibi¬ 
tion and Congress on Business, Public, and 
Home Communications, Dec. 6-9, Amster¬ 
dam. Contact H. Heringa, EuroComm 88, 
c/o RAI Gebouw bv, Europaplein, 1078 GZ 
Amsterdam, The Netherlands, phone 31 (20) 
549-1212. 


10th Israel Convention on CAD/CAM and 
Robotics (Israel Society for Computer-Aided 
Design and Manufacturing), Dec. 27-29, Tel 

Aviv. Contact Secretariat, Ortra, Ltd., PO 
Box 50432, Tel Aviv 61500, Israel, phone 
972 (3)66-48-25. 


International Seminar on Performance of 
Distributed and Parallel Systems, Dec. 7-9, 
Kyoto, Japan. Contact Yutaka Takahashi, 
Dept, of Applied Mathematics and Physics, 
Kyoto University, Kyoto 606, Japan, phone 
81 (75) 751-2111, ext. 5513. 


Z2N 1988 Winter Simulation Conference, 
'7*7 Dec. 12-14, San Diego, Calif. Contact 
Peter Haigh, NCR Corp., 1700 S. Patterson 
Blvd., SER Bldg., Dayton, OH 45479, phone 
(513)865-8042. 


Z2N ICCV 88, Second International Con- 
757 ference on Computer Vision, Dec. 
12-15, Tarpon Springs, Fla. Contact Ruzena 
Bajcsy, Computer and Information Science 
Dept., University of Pennsylvania, 200 S. 
33rd St., Philadelphia, PA 19104-6389, 
phone (215) 898-6222. 


Z2N Fourth Aerospace Computer Security 
7*7 Applications Conference (AS1S, 
AIAA, DoD, ACSA), Dec. 12-16, Orlando, 
Fla. Contact Marshall Abrams, 1820 Dolley 
Madison Blvd., McLean, VA 22101, phone 
(703) 883-6938; or Robert D. Kovach, Aer¬ 
ospace Computer Security Associates, c/o 
ORI, 1375 Piccard Dr., Rockville, MD 
20850. 


Second International Workshop of VLSI 
Design (Computer Society of India), Dec. 
15-18, Bangalore, India. Contact Ravi M. 
Apte, Valid Logic Systems, 2820 Orchard 
Pkwy, San Jose, CA 95134, phone (408) 
432-9400; or A. Prabhakar, Indian Tele¬ 
phone Industries, Dooravani Nagar, Ban¬ 
galore 560 016, India, phone 91 (812) 
563-211. 


January 1989 


International Conference on Wafer 
7^ Scale Integration, Jan. 3-5, San Fran¬ 
cisco. Contact Earl Swartzlander, TRW, 
R2/2076, 1 Space Park, Redondo Beach, CA 
90278, phone (213) 812-0791. 


22nd Hawaii International Conference 
757 on Systems Sciences, Jan. 3-6, Kailua- 
Kona, Hawaii. Contact Ralph Sprague, Jr., 
Decision Sciences Dept., University of 
Hawaii, 2404 Maile Way, E-303, Honolulu, 
HI 96822, phone (808) 948-7430. 


Impact of Recent Computer Advances on 
Operations Research (ORSA), Jan. 4-6, Wil¬ 
liamsburg, Va. Contact Ramesh Sharda, 
College of Business Administration, Okla¬ 
homa State University, Stillwater, OK 74078, 
phone (405) 624-5113. 


Second International Workshop on 
7*7 Artificial Intelligence in Economics 
and Management (IFIP, IFORS, IFAC) Jan. 
11-13, Singapore. Contact Juzar Motiwalla 
or Vicky Toh, Institute of Systems Science, 
National University of Singapore, Heng Mui 
Keng Terrace, Singapore 0511, phone (65) 
772-2075. 


February 1989 


International Symposium 1 on Databases 
7*7 for Parallel and Distributed Systems, 
Dec. 5-7, Austin, Texas. Contact Joseph E. 
Urban, Dept, of ECE, University of Miami, 
PO Box 248294, Coral Gables, FL 33124, 
phone (305) 284-3598; or Won Kim, MCC, 
3500 Balcones Center Dr., Austin, TX 
78759, phone (512) 338-3439. 


Z2X 1988 International Computer Science 
7*7 Conference, Dec. 19-21, Hong Kong. 
Contact Jean-Louis Lassez, IBM T.J. Wat¬ 
son Research Center, PO Box 218, York- 
town Heights, NY 10598; or Francis Y.L. 
Chin, Center of Computer Studies and 
Application, University of Hong Kong, 
Hong Kong. 


SIGSoft 88, Third Symposium on Software 
Development Environments (ACM), Dec. 
5-7, Boston. Contact Barry Boehm, TRW- 
DSG, 1 Space Park, R2-2086, Redondo 
Beach, CA 90278. 


Ninth Real-Time Systems Symposium, 
Dec. 6-8, Huntsville, Ala. Contact 
Walter L. Heimerdinger, Honeywell, Sys¬ 
tems & Research Center, MN65-2100, 3660 
Technology Dr., Minneapolis, MN 55418, 
phone (612) 782-7319. 


ICS 88, 1988 International Computer Sym¬ 
posium, Dec. 20-21, Taipei, Taiwan. Con¬ 
tact Louis R. Chow, Tamkang University, 
Tamsui, Taiwan, Republic of China; or Shi- 
Kuo Chang, Dept, of Computer Science, 
University of Pittsburgh, Pittsburgh, PA 
15260. 


Eighth Conference on Foundations of Soft¬ 
ware Technology and Theoretical Computer 
Science, Dec. 21-23, Pune, India. Contact 
K.V. Nori, TRDDC, 1 Mangaldas Rd., Pune 
411001, India, phone 91 (212)61-608. 


1989 IEEE Aerospace Applications Confer¬ 
ence, Feb. 5-10, Breckenridge, Colo. Con¬ 
tact Leo Mallette, Hughes Aircraft, MS: 
Bldg. R-10, A9026, PO Box 92919, Los 
Angeles 90009, phone (213) 334-2909. 


Fifth International Conference on 
7*7 Data Engineering Feb. 7-9, Los 

Angeles. Contact John Carlis, Computer 
Science Dept., University of Minnesota, 207 
Church St., SE, Minneapolis, MN 55455, 
phone (612) 625-6092; or Data Engineering 
89, Computer Society, 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202)371-1013. 


17th Computer Science Conference (ACM), 
Feb. 21-23, Louisville, Ky. Contact Confer¬ 
ence Dept. A, Assoc, for Computing 
Machinery, 11 W. 42nd St., New York, NY 
10036. 
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Z2N Compcon Spring 89, Feb. 27-Mar. 3, 

^*7 San Francisco. Contact Kenichi Miura, 
Computational Research Dept., Mail Stop 
B2-7, Fujitsu America, 3055 Orchard Dr., 
San Jose, CA 95134-2017, phone (409) 
432-1300, ext. 5408 or 5723; or Compcon 
Spring 89, Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013. 


March 1989 


EMC 89, Eighth Zurich Symposium and 
Technical Exhibition on Electromagnetic 
Compatibility (Swiss Electrotechnical 
Assoc.), Mar. 6-9, Zurich. Contact T. 
Dvorak, EMC 89, ETH Zentrum-IKT, 
CH-8092, Zurich, Switzerland, phone 41 (1) 
256-2790. 


® CAIA 89, Fifth International Confer¬ 
ence on Artificial Intelligence Applica¬ 
tions, Mar. 6-10, Miami, Fla. Contact CAIA 
89, Computer Society, 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 


Seventh National Conference on Ada Tech¬ 
nology, Mar. 13-16, Atlantic City, NJ. Con¬ 
tact Seventh National Conference on Ada 
Technology, US Army Communications— 
Electronics Command, Attn.: AMSEL-RD- 
SE-CRM (Kay Trezza), Fort Monmouth, NJ 
07703-5000, phone (201) 532-1898. 


ZZN IEEE Workshop on Visual Motion, 
Mar. 20-22, Irvine, Calif. Contact 
Ellen Hildreth, Artificial Intelligence 
Laboratory, 545 Technology Square, Cam¬ 
bridge, MA 02139; or Ramesh Jain, Electri¬ 
cal Engineering and Computer Science 
Dept., University of Michigan, Ann Arbor, 
MI 48109-2122. 


PCCC 89, Phoenix Conference on 
^57 Computers and Communications, 

Mar. 22-24, Scottsdale, Ariz. Contact Thad- 
deus Regulinski, Loral Corp., PO Box 295, 
Goodyear, AZ 85338. 


AISIG 89, Artificial Intelligence Sys- 
^*7 terns in Government Conference, Mar. 
27-31, Washington, DC. Contact AISIG 89, 
MS W418, Mitre Corp., 7525 Colshire Dr., 
McLean, VA 22102; or Computer Society, 
1730 Massachusetts Ave. NW, 20036-1903, 
phone (202)371-1013. 


Third Parallel Processing Symposium 
^4? (IEEE), Mar. 29-31, Fullerton, Calif. 
Contact Larry Canter, 1619 N. Hale, Fuller¬ 
ton, CA 92631, phone (714) 738-3414. 

Workshop on Applied Computing 89, 
^*7 Mar. 30-31, Stillwater, Okla. Contact 
Donald D. Fisher, Oklahoma State Univer¬ 


sity, CIS, Stillwater, OK 74078, phone (405) 
624-5668. 


CMC 89, Colorado Microelectronics Confer¬ 
ence, Mar. 30-31, Colorado Springs, Colo. 
Contact Conference Secretary, CMC 89, 
Microelectronics Research Laboratories, 
University of Colorado, Box 7150, Colorado 
Springs, CO 90933-7150, phone (719) 
593-3488. 


Western Educational Computing Conference 
(California Educational Computing Consor¬ 
tium), Mar. 30-31, Santa Cruz, Calif. Con¬ 
tact Judah Rosenwald, Extended Education, 
NAD 153, San Francisco State University, 
1600 Holloway, San Francisco, CA 94132, 
phone (415) 338-1212. 


Contact Ottawa Carleton Research Institute, 
1150 Morrison Dr., Suite 302, Ottawa, 
Ontario, Canada K2H 8S9, phone (613) 
726-8827. 


IEEE Infocom 89, Conference on 
Computer Communications, Apr. 
24-27, Ottawa, Canada. Contact J.W. Mark, 
IEEE Infocom 89, Dept, of Electrical 
Engineering, University of Waterloo, Water¬ 
loo, Ontario, Canada N2L 3G1, phone (519) 
888-4016. 


Vision 89 (SME), Apr. 25-27, Chicago. Con¬ 
tact Maria Nowakowski, Society of Manu¬ 
facturing Engineers, 1 SME Dr., PO Box 
930, Dearborn, MI 48121, phone (313) 
271-1500, ext. 376. 


April 1989 


Second IEE National Conference on 
Telecommunications, Apr. 2-5, York, 
England. Contact IEE Conference Services, 
Savoy PL, London WC2R 0BL, UK, phone 
44(1)240-1871, ext. 222. 


Z2N ASPLOS III, Third International Con- 
^7 ference on Architectural Support for 
Programming Languages and Operating Sys¬ 
tems (ACM), Apr. 3-6, Boston. Contact Joel 
Emer, DEC/MIT, 545 Technology Square 
(NE43-503), Cambridge, MA 02139. 


Zg, CHI 89, Conference on Human Fac- 
tors in Computing Systems (ACM, 
HFS), Apr. 30-May 4, Austin, Texas. Con¬ 
tact Claudia Raun or Bill Curtis, MCC, PO 
Box 200195, Austin, TX 78720, phone (512) 
338-3798. 


34th International Instrumentation Sympo¬ 
sium (ISA), Apr. 30-May 4, Orlando, Fla. 
Contact Frederick A. Kern, PO Box 65, 
Seaford, VA 23696, phone (804) 865-3269. 


May 1989 


IFIP TC-2 Working Conference on Visual 
Database Systems (IPSJ), Apr. 3-7, Tokyo. 
Contact IFIP TC-2 Working Conference, 
Tosiyasu L. Kunii, Dept, of Information 
Science, Faculty of Science, University of 
Tokyo, 7-3-1 Hongo, Bunkyo-ku, Tokyo 
113, Japan, phone 81 (3) 812-2111, ext. 
4116. 


CompEuro 89, International Confer¬ 
ence on VLSI and Computer 
Peripherals, May 8-12, Hamburg. Contact 
Walter E. Proebster, IBM Laboratory, PO 
Box 1380, D-7030 Boeblingen, Federal 
Republic of Germany, phone 49 (70) 
3116-3929. 


MIV 89, International Workshop on Indus¬ 
trial Applications of Machine Intelligence 
and Vision (IEEE), Apr. 10-12, Tokyo. Con¬ 
tact Mitsuru Ishizuka, Institute of Industrial 
Science, University of Tokyo, 7-22-1, Rop- 
pongi, Minato-ku, Tokyo, 106, Japan, 
phone 81 (03)470-5389. 


ICCAL 89, Second International Conference 
on Computer-Assisted Learning (Computer 
Learning Research Center), May 9-11, 

Dallas. Contact Janet Harris, Center for 
Continuing Education, University of Texas 
at Dallas, PO Box 830688, MS CN 1.1, 
Richardson, TX 75083-0688. 


International Symposium on Database 
^57 Systems for Advanced Applications 
(IPSJ, KISS), Apr. 10-12, Seoul, Korea. 
Contact Sukho Lee, Dept, of Computer 
Engineering, Seoul National University, 
Sinlim-Dong, Gwanak-Ku, Seoul 151, 
Korea, phone 82 (2) 886-0101. 


ETC 89, First European Test Conference, 
Apr. 12-14, Paris. Contact Colin Maunder, 
British Telecom Research Laboratories, 
Martlesham Heath, Ipswich, Suffolk IP5 
7RE, phone 44 (473) 642-706. 


Multimedia 89, Second IEEE Comsoc Inter¬ 
national Multimedia Communications 
Workshop, Apr. 20-23, Ottawa, Canada. 


CCC 89, Second Hungarian Custom Circuit 
Conference (MATE), May 10-12, Szeged, 
Hungary. Contact MATE Secretariat, 1055 
Budapest, Kossuth L. ter 6-8, Hungary, 
phone (1)531-406. 

1989 IEEE International Conference on 
Robotics and Automation, May 14-19, 

Scottsdale, Ariz. Contact Harry Hayman, 
PO Box 3216, Silver Spring, MD 20901, 
phone (301) 434-1990 or (407) 483-3037. 


11th International Conference on Soft- 
ware Engineering (ACM), May 15-18, 

Pittsburgh. Contact Larry Druffel, Software 
Engineering Institute, Carnegie Mellon Uni¬ 
versity, Pittsburgh, PA 15213-3890, phone 
(412) 268-7740. 
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CALL FOR PAPERS 


Call for papers and referees for Computer 


Computer seeks articles for inclusion in 
two upcoming special issues. 


Rapid Prototyping will be the theme of 
the May 1989 issue. 

Suggested topics include 

• the role of knowledge engineering in 
prototyping environments; 

• rapid prototyping of real-time systems; 

• domain-specific rapid prototyping 
systems; 

• reusability in prototyping envi¬ 
ronments; 

• support tools for prototyping envi¬ 
ronments; 

• prototyping experience with ART, 
KEE, PC + , etc.; 

• prototyping experience with C + +, 
Smalltalk, Flavors Objective-C, Ada, 
etc.; and 

• prototyping experience with CASE 


Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract should be submitted 
as soon as possible. Eight copies of the 
full manuscript should be submitted by 
Sept. 1, 1988 to Murat M. Tanik, Com¬ 
puter Science and Engineering Depart¬ 


ment, Southern Methodist University, 
Dallas, TX 75275, phone (214) 692-2854, 
E-mail: smu.tanik@uunet.uu.net; or to 
Raymond T. Yeh, ISS1 International, 
9420 Research Blvd., Suite 2000, Austin, 
TX 78759, phone (512) 338-1895, csnet: 
issi@emx.utexas.edu. 

Authors will be notified of acceptance by 
l)cc. 1, 1988. The final version of the 
manuscript is due no later than Jan. 1, 
1989. 

Persons interested in serving as referees 
are asked to send a note with a list of 
technical interests to Tanik or to Bruce 
D. Shriver, Computer Editor-in-Chief, 
Department of Decision Sciences, Uni¬ 
versity of Hawaii, 2404 Maile Way, 
Honolulu, HI 96822. 


Autonomous Intelligent Machines is the 

theme scheduled for the June 1989 issue. 

Suggested topics include 

• distributed and parallel architectures 
for intelligent machines; 

• multisensor integration for intelligent 
machine applications; 

• real-time control and coordination of 
mobile robots and manipulators; 

• machine intelligence and expert 
systems; 


• robot programming; 

• path planning and navigation; and 

• learning and autonomous machines. 

Papers must not have been previously 
published or currently submitted for pub¬ 
lication elsewhere. 

A 300-word abstract should be submitted 
as soon as possible. Eight copies of the 
full manuscript must be submitted by 
Oct. 1, 1988 to S. Sitharama Iyengar, 
Department of Computer Science, Loui¬ 
siana State University, Baton Rouge, LA 
70803-4020, phone (504) 388-1495, E- 
mail: iyengar%lsu.edu@relay.csnet; or 
to Rangasami L. Kashyap, Department 
of Electrical Engineering, Purdue Univer¬ 
sity, West Lafayette, IN 47907, phone 
(317) 494-3473, csnet E-mail address: 
kashyap@ee.ecn.purdue.edu. 

Authors will be notified of acceptance by 
Jan. 10, 1989. The final version of the 
manuscript is due no later than Feb. 25, 
1989. 

Persons interested in serving as referees 
are asked to send a note with a list of 
technical interests to Iyengar, Kashyap, 
or Bruce D. Shriver, Computer Editor-in- 
Chief, Department of Decision Sciences, 
University of Hawaii, 2404 Maile Way, 
Honolulu, HI 96822. 


IEEE Transactions on Knowledge and 
Data Engineering will begin publica¬ 
tion in Spring 1989. Papers are sought, par¬ 
ticularly those emphasizing research, design, 
and development of knowledge and data- 
engineering methodologies, strategies, and 
systems. For information and submission 
requirements, contact C.V. Ramamoorthy, 
Computer Science Division, University of 
California, Berkeley, CA 94720, phone (415) 
642-4751; or B.W. Wah, Coordinated 
Science Laboratory, University of Illinois, 
Urbana, IL 61801, phone (217) 333-3516. 


34th International Instrumentation Sympo¬ 
sium (ISA): Apr. 30-May 4, 1989, Orlando, 
Fla. Submit paper by Aug. 15, 1988 to 
Frederick A. Kern, PO Box 65, Seaford, VA 
23696, phone (804) 865-3269. 

First International Symposium on Artificial 
Intelligence: Oct. 24-28, 1988, Monterrey, 
Mexico. Submit paper by Aug. 31, 1988 to 
Francisco J. Cantu, Instituto Tecnologico de 
Monterrey, ITESM Sue. Correos “J”, Mon¬ 
terrey N.L., Mexico, 64849, phone 52 (83) 
59-59-43. 


CompEuro 89, International Confer- 
ence on VLSI and Computer Periph¬ 
erals: May 8-12, 1989, Hamburg. Submit 
paper by Aug. 15, 1988 to Walter E. Proeb- 
ster, IBM Laboratory, PO Box 1380, D-7030 
Boeblinger, Federal Republic of Germany. 


IEEE Globecom 88: Dec. 1-2, 1988, Holly¬ 
wood, Fla. Submit paper by Aug. 15, 1988 to 
Dennis J. Sassa, Bell Communications 
Research, NVC 2Z-129, 331 Newman 
Springs Rd„ Red Bank, NJ 07701-7020, 
phone (201) 446-6787. 


10th Israel Convention on CAD/CAM and 
Robotics (Israel Society for Computer-Aided 
Design and Manufacturing): Dec. 27-29, 
1988, Tel-Aviv. Submit abstract by Aug. 31, 
1988 to Secretariat, Ortra Ltd., PO Box 
50432, Tel Aviv 61500, Israel, phone 972 (3) 
66-48-25. 


IEEE Software: May 1989. Articles are 
sought for a special issue on verifica¬ 
tion and validation. Submit manuscript by 
Sept. 1, 1988 to Dolores Wallace, National 
Bureau of Standards, B-266 Technology 


Bldg., Gaithersburg, MD 20899, phone (301) 
975-3340. 


17th Computer Science Conference (ACM): 
Feb. 21-23, 1989, Louisville, Ky. Submit 
paper by Sept. 1, 1988 to John D. 

McGregor, Dept, of Computer Studies, 
Murray State University, Murray, KY 42071, 
phone (502) 762-6214. 

1989 IEEE Aerospace Applications Confer¬ 
ence: Feb. 5-10, 1989, Breckenridge, Colo. 
Submit summary by Sept. 6, 1988 to Leo 
Mallette, Hughes Aircraft, MS: Bldg. R-10, 
A9026, PO Box 92919, Los Angeles 90009, 
phone (213)334-2909. 

SIGMetrics 89 and Performance 89 (ACM, 
IFIP): May 23-26, 1989, Berkeley, Calif. 
Submit paper by Sept. 10, 1988 to Alan J. 
Smith, Computer Science Division, Univer¬ 
sity of California, Berkeley, CA 94720. 


® 11th International Conference on Soft¬ 
ware Engineering (ACM): May 15-18, 
1989, Pittsburgh. Submit paper by Sept. 15, 
1988 to Richard Fairley, School of Informa- 
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INTERNATIONAL CONFERENCE ON FIFTH GENERATION COMPOTER SYSTEMS 1980 

NOVEMBER 28 (Mon.)—DECEMBER 2 (Fri.), 1988 TOKYO, JAPAN 


The FGCS Conference, with two predecessors held in 1981 and 1984, has received high 
ratings as an event that provides an opportunity for many distinguished scholars, top-class 
research engineers, and highcaliber business and government people to gather from all 
over the world to report research results and exchange opinions. We look forward to your 
participation in the Conference. 


GENERAL INFORMATION 

HOST: 

Institute for New Generation Computer Technology 
(ICOT) 

SUPPORT: 

Ministry of International Trade and Industry (MITI) 

COOPERATION: 

• Information Processing Society of Japan 

• The Institute of Electronics, Information and 
Communication Engineers 

• Japanese Society for Artificial Intelligence 

• Japan Society for Software Science and Technology 

• The Computer Society of the IEEE 

• Association for Computing Machinery 

DEMONSTRATION: 

Intermediate research results of the Japanese FGCS 
project will be demonstrated. 

REGISTRATION FEE: 

¥90,000 by September 30,1988 
¥110,000 after October 1,1988 

APPLICATION: 

Those who wish to make a registration for the 
conference, please request Registration Form to the 
Secretariat. 

ORGANIZATION: 

Steering Committee 

Conference Chairman: Hideo Aiso, Keio Univ. 
Vice-Chairman :Kazuhiro Fuchi, ICOT 
Program Committee 

Chairman :Hidehiko Tanaka, Univ. of Tokyo 
Vice-Chairman :Koichi Furukawa, ICOT 
The Program Committee is composed of 57 members 
from 10 countries. 


CONFERENCE SCHEDULE 

PLENARY SESSIONS Nov. 28-Nov. 29 

• OPENING SESSION 

• PANEL DISCUSSION 

Social Impact of Information Technology & International 
Collaboration 

• INVITED LECTURES 
Herbert A. Simon 
(Carnegie Mellon Univ., U.S.A.) 

Keith Clark 

(Imperial College, U.K.) 

• REPORT ON ICOT’S PROGRESS 

TECHNICAL SESSIONS Nov. 30-Dec. 2 

• INVITED PAPERS 

Robin Milner (Univ. of Edinburgh, U.K.) 

Yoshihiko Futamura (Hitachi, Ltd., Japan) 

David H.D. Warren (Univ. of Manchester, U.K.) 

Herve Gallaire (ECRC, F.R.G.) 

• SPECIAL SESSIONS 

Messages from Parallel Complexity - Does Parallelism Help?- 
Meta-computation and Reflection 
New Paradigms of Knowledge Acquisition 
Progress and Future Plans of Knowledge Information 
Processing 

ICOT Research Topics 

• PRESENTATION of about 90 papers selected from 357 
submitted papers. 

• PANEL DISCUSSION 

Theory and Practice of Concurrent Systems 


FGCS’88 Secretariat: 

Institute for New Generation Computer Technology (ICOT) 

Mita Kokusai Bldg. 21F, 1-4-28 Mita, Minato-ku, Tokyo 108, Japan 
Phone:03(456)3195 Telex:32964 ICOTJ 






tion Technology, George Mason University, 
Fairfax, VA 22030; or Dines Bjorner, Dansk 
Datamatik Center, Lundtoftevej 1 C, 

Lyngby DK-2800, Denmark. 

Transactions on Systems, Man, and Cyber¬ 
netics will publish a special issue on un¬ 
manned systems and vehicles. Submit 
abstract by Sept. 15, 1988 and full paper by 
Nov. 1, 1988 to Arun K. Sood, Dept, of 
Computer Science, George Mason Univer¬ 
sity, 4400 University Dr., Fairfax, VA 
22030-4400, phone (703) 323-2713. 

1CCAL 89, Second International Conference 
on Computer-Assisted Learning (Computer 
Learning Research Center): May 9-11, 1989, 
Dallas. Submit extended abstract by Sept. 

15, 1988 Hermann Maurer, IIG, Schiesstatt- 
gasse 4a, A-8010 Graz, Austria, phone 43 
(316)70-255. 

£3^ CHI 89, Conference on Human Fac- 
vsy tors in Computing Systems (ACM, 
HFS): Apr. 30-May 4, 1989, Austin, Texas. 
Submit paper by Sept. 26, 1988 to Clayton 
Lewis, Dept, of Computer Science, Campus 
Box 430, University of Colorado, Boulder, 
CO 80309, phone (303) 492-6657. 

ACM’s SlGArl newsletter plans a special 
issue on knowledge acquisition in April 1989. 
Submit extended abstract or paper by Sept. 
26, 1988 to Christopher Westphal, Knowl¬ 
edge Acquisition Material, BDM Corp., 

7915 Jones Branch Dr., McLean, VA 22102, 
phone (703) 848-7910. 

International Symposium on Database Sys¬ 
tems for Advanced Applications (IPSJ, 
KISS): Apr. 10-12, 1989, Seoul, Korea. Sub¬ 
mit paper by Sept. 30, 1988 to In-Sup Paik, 
Data Communications Corp. of Korea, 
65-228, 3-Ga, Hangang-Ro, Yongoan-Ku, 
Seoul 140, Korea, phone 82 (02) 796-6606. 

CAPE 89, Computer Application in Produc¬ 
tion Engineering Conference (IFIP, IPSJ, 
JSPE): Oct. 2-5, 1989, Tokyo. Submit 
extended abstract by Sept. 30, 1988 to Busi¬ 
ness Center for Academic Societies of Japan, 
2-40-14, Hongo, Bunkyo-ku, Tokyo 113, 
Japan, phone 81 (3) 817-5831. 


CMC 89, Colorado Microelectronics Confer¬ 
ence: Mar. 30-31, 1989, Colorado Springs, 
Colo. Submit abstract by Oct. 1, 1988 to 
Technical Chair, CMC 89, Microelectronics 
Research Laboratories, University of 
Colorado, Box 7150, Colorado Springs, CO 
90933-7150. 

Multimedia 89, Second IEEE Comsoc Inter¬ 
national Multimedia Communications 
Workshop: Apr. 20-23, 1989, Ottawa, Can¬ 
ada. Submit abstract by Oct. 1, 1988 to Nic¬ 
olas D. Georganas, Multimedia 89, Facul¬ 
ty of Engineering, University of Ottawa, 
Ottawa, Ontario, Canada KIN 6N5, phone 
(613)564-8222. 

1989 IEEE International Conference on 
Robotics and Automation: May 14-19, 1989, 
Scottsdale, Ariz. Submit paper by Oct. 1, 
1988 to John M. Hollerbach, MIT Artificial 


Intelligence Laboratory, 545 Technology 
Square, Cambridge, MA 02139. 


FTCS 19, International Symposium on 
Fault-Tolerant Computing: June 
21-23, 1989, Chicago. Submit abstract by 
Oct. 14, 1988 and final manuscript by Nov. 
21, 1988 to S.M. Reddy, FTCS 19, Dept, of 
Electrical and Computer Engineering, Uni¬ 
versity of Iowa, Iowa City, Iowa 52242, 
phone (319) 335-5196. 


Ninth International Conference on 
Distributed Computing Systems: June 
5-9, 1989, Newport Beach, Calif. Submit 
paper by Oct. 15, 1988 to Norman Schneide- 
wind, Naval Postgraduate School, Code 
54Ss, Monterey, CA 93943. 


Fifth International Workshop on Software 
Specification and Design: May 19-20, 1989, 
Pittsburgh. Submit extended abstract or 
paper by Oct. 15, 1988 to Colin Potts, MCC, 
9390 Research Blvd., Kaleido II Bldg., Aus¬ 
tin, TX 78759, phone (512) 338-3629. 


SETSS 90, Seventh International Conference 
on Software Engineering for Telecommuni¬ 
cations Switching Systems (IEE): July 3-6, 
1989, Bournemouth, England. Submit syn¬ 
opsis by Oct. 26, 1988 to Conference Ser¬ 
vices, Institution of Electrical Engineering, 
Savoy PL, London WC2R 0BL, UK, phone 
44(1)24-01-871. 


CHDL 89, Ninth International Symposium 
on Computer Hardware Description Lan¬ 
guages and Applications: June 19-21, 1989, 
Washington, DC. Submit paper by Oct. 31, 
1988 to Franz Rammig, University of Pader- 
born, Warburger Str. 100, D4790 Pader- 
born, Federal Republic of Germany. 

HCI International 89, Third International 
Conference on Human-Computer Interac¬ 
tion: Sept. 18-22, 1989, Boston. Submit 
abstract by Oct. 31, 1988 Gavriel Salvendy, 
School of Industrial Engineering, Grissom 
Hall, Purdue University, West Lafayette, IN 
47907, phone (317) 494-5426. 


® IEEE Software: July 1989. Articles are 
sought for a special edition on parallel¬ 
processing languages. Submit manuscript by 
Nov. 1, 1988 to Shreekant Thakkar, Sequent 
Computer Systems, 15450 SW Koll Pkwy., 
Beaverton, OR 97006, phone (503) 627-9822. 

IEEE Transactions on Computers 
plans a special issue on distributed 
computing systems in August 1989. Submit 
manuscript by Nov. 1, 1988 to Steve S. Yau, 
Computer and Information Sciences Dept., 
University of Florida, Gainesville, FL 32611, 
phone (904) 335-8000. 


Third International Conference on Image 
Processing (IEE): July 18-20, 1989, War¬ 
wick, England. Submit paper by Nov. 1, 
1988 to Conference Services, Institution of 
Electrical Engineers, Savoy PL, London 
WC2R 0BL, phone 44 (1) 24-01-871, ext. 
222. 


IFIP Congress 89, Uth World Computer 

Congress: Aug. 28-Sept. 1, 1989, San Fran¬ 


cisco. Submit paper by Nov. 1, 1988 to 
Herve Gallaire, ECRC, Arabellastrasse 17, 
D-8000 Munich 81, Federal Republic of Ger¬ 
many, phone 49 (89) 92-69-91-00. 

16th EATCS, Colloquium on Automata, 
Languages, and Programming: July 11-15, 
1989, Stresa, Italy. Submit extended abstract 
by Nov. 15, 1988 and manuscript by Feb. 15, 
1989 to S. Ronchi Della Rocca, Diparti- 
mento di Informatica, corso Svizzera 185, 
10149 Torino, Italy, phone 39(11)75-56-77. 

1989 International Computers in Engineering 
Conference (ASME): July 30-Aug. 2, 1989, 
Anaheim, Calif. Submit paper by Nov. 15, 
1988 to Donald R. Riley, Mechanical Engi¬ 
neering Dept., University of Minnesota, 111 
Church St. SE, Minneapolis, MN 55455. 


® CVPR 89, Conference on Computer 
Vision and Pattern Recognition: June 
4-8, 1989, San Diego, Calif. Submit paper by 
Nov. 16, 1988 to Worthy Martin, Dept, of 
Computer Science, University of Virginia, 
Charlottesville, VA 22903. 


MIV 89, International Workshop on Indus¬ 
trial Applications of Machine Intelligence 
and Vision (IEEE): Apr. 10-12, 1989, Tokyo. 
Submit summary by Nov. 21, 1988 to Mit- 
suru Ishizuka, Institute of Industrial Science, 
University of Tokyo, 7-22-1, Roppongi, 
Minato-ku, Tokyo, 106, Japan, phone 81 (3) 
470-5389. 


10th Tunisian French Seminar of Computer 

Science: Spring 1989, Tunis, Tunisia. Submit 
paper by Nov. 30, 1988 to Ali Mili, Faculty 
of Sciences, University of Tunis II, Campus 
Universitaire, 1002 Belvedere, Tunisia. 

Seventh National Conference on Ada Tech¬ 
nology: Mar. 13-16, 1989, Atlantic City, NJ. 
Submit summary by Dec. 9, 1988 to Seventh 
National Conference on Ada Technology, 

US Army Communications—Electronics 
Command, Attn.: AMSEL-RD-SE-CRM 
(Kay Trezza), Fort Monmouth, NJ 
07703-5000, phone (201) 532-1898. 

11th International Joint Conference on Arti¬ 
ficial Intelligence (1JCAII, AAAI): Aug. 
20-26, 1989, Detroit. Submit paper by Dec. 
12, 1988 to N.S. Sridharan, Central Engi¬ 
neering Laboratories, FMC Corp., 1205 
Coleman Ave., Box 580, Santa Clara, CA 
95052, phone (408) 289-0315. 


ASE 89, International Conference on Appli¬ 
cations of Supercomputers in Engineering: 

Sept. 5-7, 1989, Southampton, England. 
Submit paper by Dec. 30, 1988 to Liz New¬ 
man, Computational Mechanics Institute, 
Ashurst Lodge, Ashurst, Southampton, S04 
2AA, England, UK, phone 44 (0) 
42-12-92-853. 


® Third Parallel Processing Symposium 

(IEEE): Mar. 29-31, 1989, Fullerton, 
Calif. Submit abstract by Jan. 6, 1989 and 
paper by Feb. 6, 1989 to Larry Canter, 1619 
N. Hale, Fullerton, CA 92631, phone (714) 
738-3414. 
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THE NEW 

IEEE TRANSACTIONS ON 
KNOWLEDGE AND DATA ENGINEERING 


THE COMPUTER SOCIETY 


The new quarterlyTRANSACTIONS ON KNOWLEDGE AND DATA 
ENGINEERING aims to provide an international and interdisciplinary 
forum to publish results on the research, design, and development of 
knowledge and data engineering methodologies, strategies and sys¬ 
tems. March 1989 will be the first issue. 


(f) designs to provide increased intelligence and ease of use through 
speech, voice, graphics, images and documents; 


(h) the development of ways to prolong the useful life of knowledge 
and data and its graceful degradation. 



Researchers, developers, managers, strategic planners, users, and 
others interested in state-of-the-art and state-of-the-practice activities 
in the knowledge and data engineering area 



The key technical issues this Transactions will address include 


(a) acquiring and managing knowledge and data in developing and 
using information systems; 

(b) strategies to capture and store new knowledge and data; 

(c) methods to lessen the burden of software and hardware develop¬ 
ment and maintenance; 

(d) mechanisms to provide system modeling, design, access, and 
security and integrity control; 

(e) architectures, systems, and components to provide knowledge 
and data services within centralized and distributed information sys¬ 
tems; 


SOME PERTINENT DATA AND KNOWLEDGE 
ENGINEERING TOPICS TO BE ADDRESSED 


• Artificial Intelligence techniques 

• Knowledge and data engineering tools and techniques 

• Parallel and distributed processing 

• Real-time knowledge bases and databases 

• System architectures, integration and modeling 

• Database design, modeling and management 

• Query, design, and implementation languages 

• Distributed database control 

• Statistical databases 

• Algorithms for data and knowledge management 

• Performance evaluation of algorithms and systems 

• Data communications aspects 

• System applications and experience 

• Knowledge-based and expert systems 

• Integrity, security and fault tolerance 


ARTICLE GUIDELINES 



This new periodical is at the Transactions level. The selection of arti¬ 
cles for publication will follow the guidelines used by other IEEE Com¬ 
puter Society Transactions, such as the IEEE TRANSACTIONS ON 
SOFTWARE ENGINEERING. A minimum of three reviews will be re¬ 
quired for a decision to be made on each paper. 



This Transactions will publish original results in research and devel¬ 
opment in areas relevant to knowledge and data engineering. Papers 
that can be submitted for consideration include those that have not 
previously been published in another journal, or are not currently 
being published, as well as those that have been published in Confer¬ 
ence Proceedings, Digests, and Records and that have undergone 
substantial revision. Invited papers from leading authorities in the 
knowledge and data engineering area will also be published. Three 
types of papers will be published: 

(1) Regular technical articles, which contribute to the understanding 
and advances in the knowledge and data engineering area (25-35 
double spaced pages, including figures, tables, and references): 

(a) papers with extensive original results and 

(b) in-depth surveys; 

(2) Concise short articles (maximum 12 pages): papers with results 
that are important and original and are presented in a concise form; 

(3) Correspondence articles (maximum 3 pages): comments on previ¬ 
ously published articles, short extensions to current results, critiques 
on previous results, responses from authors, and corrections to prevj 1 
ously published articles. An effort will be made to shorten the turn¬ 
around time for concise papers and correspondence articles. 


giTdelines for submitting papers and 

PROPOSALS ON SPECIAL ISSUES_ 


(1) For invited papers and proposals for special issues, send 6 
copies to: 

C. V. Ramamoorthy, Editor-in-Chief 
Computer Science Division 
University of California, Berkeley 
Berkeley, CA 94720 
(415)642-4751, (415)642-1898 
ram@ernie.berkeley.edu 

(2) For all other submissions, send 6 copies of manuscript, complete 
with illustrations, abstract, and index terms, to: 

Benjamin W. Wah, Associate Editor-in-Chief 
Coordinated Science Laboratory 
University of Illinois at Urbana-Champaign 
1101 West Springfield Avenue 
Urbana, IL 61801 
(217) 333-3516, (217) 244-7175 
wah%aquinas@uxc.cso.uiuc.edu 

IEEE copyright transfer form and general guidelines for submissions 
can be found in the January 1988 issue of IEEE TRANSACTIONS 
ON SOFTWARE ENGINEERING. 



Any questions regarding the journal can be directed to either listed 
Editor. For complete submission guidelines, circle the reader service 
card at the back of this magazine. 


Reader Service Number 7 



















BOOK REVIEWS 


Editor: Wiley McKinzie, School of Computer Science and Technology, Rochester Institute of Technology, Rochester, NY 14623; Compmail, w.mckinzie; CSnet, wrm@rit 


Principles of Software Engineering Management 


Tom Gilb with Susannah Finzi 

(Addison-Wesley, Reading, Mass., 

1988, 442 pp., $34.50) 

To be useful, a book must change 
you in some way. If you read it from 
cover to cover and agree with every sin¬ 
gle word but don’t change, then both 
you and the author have wasted your 

Effecting change in the reader is a tall 
order. To pull it off, an author needs to 
provide fresh insight, combined with 
clear, persuasive presentation. Tom 
Gilb has put plenty of each in his new 
book, Principles of Software Engineer¬ 
ing Management. The work leaves your 
head spinning, thinking of all the 
missed opportunities on your last proj¬ 
ect and how differently you will 
approach your next one. For an invest¬ 
ment of a few hours’ reading, virtually 
any software manager’s work will be 
changed in so many aspects that a vet¬ 
eran observer may be inclined to 
remark, “1 see you’ve been reading 
Gilb.” 

Gilb has always marched to a differ¬ 
ent drum. From his very first work, the 
classic Software Metrics (Winthrop, 
1977), he has demonstrated a flair for 
original thought—sometimes too origi¬ 
nal. I remember looking through that 
book and wondering, “If these ideas 
are as sensible as they seem to be, why 
isn’t anyone else suggesting them?” Of 
course, no one else had thought of 
them. 

Software Metrics was chock full of 
wisdom about the software develop¬ 
ment process, but I don’t believe it ever 
had much impact. The book was just 
too unsettling. Readers who would have 
been delighted to encounter a single 
startling insight were troubled to find 
dozens of them. A simple insight, after 
all, is the mark of a bright fellow 
worker, slogging away with the rest of 
us but just a bit more alert. Dozens of 
fresh insights, however, suggest a mind 


that works differently. Gilb’s 1977 
book might have been written by Mork 
from Ork. 

Part of the problem with Software 
Metrics and the scores of articles Gilb 
has published over the past decade is 
the manic enthusiasm and wildly vary¬ 
ing focus of his writing. On a single 
page, you could encounter suggestions 
for managing, measuring, motivating, 
specifying, coding, testing, and some¬ 
times even running your personal life. 

All that has changed in Principles of 
Software Engineering Management. 

The book is narrowly focused, dis¬ 
ciplined, lucid, and very convincing. On 
the cover Gilb is cited alone as author, 
but on the title page the author credit 
reads, “Tom Gilb with Susannah 


The work leaves your 
head spinning, thinking 
of all the missed 
opportunities on your 
last project. 


Finzi.” If Susannah Finzi is responsible 
for the improved presentation quality, 
then the world desperately needs more 
Susannah Finzis. 

At its heart, the book is a thoughtful 
presentation of two disarmingly simple 
and obvious ideas. When you’re done 
reading, you’re half convinced you 
always knew the ideas were true. (But 
why, then, have you always managed 
with such flagrant disregard for them?) 
Important truths always seem obvious 
after someone has pointed them out to 
you. The two ideas are these: 

(1) fVe must q uantify e verything tha t 
matters to eventual project success or 


failure. Everything—particularly those 
product characteristics that we treat as 
unquantifiable (flexibility, “user- 
friendliness,” net benefit, etc.)—must 
be scaled and targeted. Some of our 
quantifications will be “fuzzy” in 
Gilb’s terms, but even fuzzy numbers 
are far better than no numbers at all. 
The very act of coming up with the 
best-effort quantification of these fac¬ 
tors guides us toward success and know¬ 
ing how well we’re doing along the way. 

.Consider matching a new system to 
the buyer’s need s. On mostprojects the 
extent of match is not even discussed. 
The project has an implicit goal of 
“high” match, whatever that means. 
Gilb would instead have us state the 
goal explicitly in terms of maximum- 

aggregate Hnllars nf requ ested cha nge 
during theproject and the post-project 
period. If those measures are too coarse 
for your taste, it’s up to you to refine 
them. 

(2) We must move the deliv erv-oro- 
cess away from “big bang" or 
‘ 'phased 1 ' delivery to “evolutionary ” 
developmen t. In this scheme the system 
isconstructed in tiny, incremental steps, 
each one providing some of the benefit 
of the whole system. We see some of 
this in most modern organizations, but 
Gilb advocates an extreme form. If you 
organize as he suggests, you can demon¬ 
strate to yourself that you have max¬ 
imized visibility and available benefit at 
each point in the project. Even if your 
project is late, you can optimally defend 
your position; any alternative strategy 
would have resulted in more lateness 
with less delivered benefit by the origi¬ 
nally specified date. 

The synthesis of these two ideas into 
a workable scheme for managing soft¬ 
ware projects is the crux of Gilb’s new 
book. It’s a winner. 


Tom DeMarco 
Atlantic Systems Guild 
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Telecommunication Networks: 
Protocols, Modeling and Analysis 


Mischa Schwartz (Addison-Wesley, 

Reading, Mass., 1987, 749 pp., 

$49.50) 

The author’s work as a teacher and a 
telecommunications expert provides the 
basis for Telecommunication Networks, 
in which he attempts to describe the 
changes in telecommunications over the 
last two decades. Given the enormous 
amount of material to cover, he does an 
excellent job of presenting a variety of 
detailed material on packet-switching 
and circuit-switching networks. The 
work on quantitative performance 
evaluation is particularly gratifying. 

In the first three chapters Schwartz 
introduces circuit switching and packet 
switching, layered architectures, and 
queueing theory. He then discusses 
packet-switching networks in Chapters 
4-9 and circuit-switching networks in 
Chapters 10-12. 

Integrated networks are introduced in 
Chapter 12. The OSI reference model 
provides a framework for the discus¬ 
sion, which extends through the trans¬ 
port layer. Schwartz analyzes many 
networking protocols, particularly in 
the area of routing. Examples include 
HDLC at the data-link layer; X.25 and 
SNA at the network layer; TCP at the 
transport layer; Aloha in the discussion 
of random-access techniques; Ethernet 
and the IEEE 802 standards in the dis¬ 
cussion of local area networks; and 
AT&T No. 4 ESS and Italtel UT 10/3 in 
the discussion of digital switching systems. 

Telecommunication Networks is an 
appropriate text for senior/graduate 
level students and contains sufficient 
material for two semesters of work. 
Even an experienced network analyst 
would find this a convenient reference 
book, and any computer scientist 
interested in computer networks would 
find it intriguing. 

Although Schwartz suggests that an 
introductory course could be assembled 
from certain chapters, I feel that 
Telecommunication Networks is inap¬ 
propriate for an overview. Other books 
on networking, such as Andrew Tanen- 
baum’s Computer Networks (Prentice- 
Hall, 1981), discuss computer commu¬ 
nications in the context of the entire 
OSI reference model. Schwartz limits 
the value of Telecommunication Net¬ 
works by not discussing the session, 
presentation, and application layers in 
more detail. 

Telecommunication Networks is an 
excellent, self-contained technical dis¬ 
cussion of networking standards, 


telecommunication network protocols, 
and their analysis. The author analyzes 
most major networking protocols in 
some detail. The frequently conversa¬ 
tional style—probably due to the 
material’s derivation from classroom 
presentations—occasionally jars the 
reader. Other texts provide a more read¬ 
able description of networking pro¬ 
tocols and standards, but the value of 
Telecommunication Networks lies in its 
quantitative performance analysis of 
networks. 


Even an experienced 
network analyst would 
find this a convenient 
reference book. 


The errors are comparatively minor. 
For example, Figure 1-3 does not ade¬ 
quately illustrate the discussion of gate¬ 
ways and network interconnection. The 
reader must puzzle out that the labeled 
gateways are embedded in network 
switches and the unlabeled gateways are 
network nodes—if indeed this is the 
correct interpretation (Schwartz states 
that both types of gateway are in the 
figure). A picture can either illuminate 
or obscure a point. In this case the 
graphic confuses the discussion. 

Although containing more than 200 
entries, the reference list omits many 
papers I have found valuable. These 
include Gerla and Kleinrock’s “Flow 
Control: A Comparative Survey” 

(IEEE Trans. Communications, May 
1980) and Schoch and Hupp’s “Mea¬ 
sured Performance of an Ethernet 
Local Network” (Comm. ACM, Dec. 
1980), which are directly relevant to 
major sections in the book. However, 
these omissions illustrate the level of 
activity in computer networks over the 
last two decades; an exhaustive refer¬ 
ence list would be several hundred pages 
long. 

Telecommunication Networks is a 
valuable addition to my bookshelf. It 
offers an enormous amount of informa¬ 
tion on quantifying telecommunication 
networks and examining the tradeoffs 
between various approaches. 1 consider 
it one of the best books in print on com¬ 
puter networks, and I recommend it 
highly. 

Mark C. Paulk 

Software Engineering Institute 


Inside OS/2 

Gordon Letwin (Microsoft Press, 

Redmond, Wash., 1988, 281 pp., 

$19.95) 

The chief architect of OS/2 wrote this 
book to provide a general understand¬ 
ing of the operating system’s role in the 
world of microcomputers, the issues 
faced by its designers, and the 
approaches used to address these issues. 

OS/2 is a multitasking operating sys¬ 
tem that exploits the memory manage¬ 
ment and protection features of the 
80286 and 80386 processors. It differs 
from traditional multitasking operating 
systems in its implementation of such 
functions as multitasking, scheduling, 
disk management, and memory 
management. In his book, Letwin dis¬ 
cusses the motivation for these differ¬ 
ences and the design strategy for 
implementing them. 

The designers of OS/2 faced a host of 
problems due to the environment the 
system is envisioned to support. For 
example, Microsoft conceived OS/2 as 
the operating system for the automated 
office of the future, in which knowledge 
workers use personal computers that 
can perform more than one chore at a 
time and rapidly manipulate large quan¬ 
tities of graphics and text information. 
Thus the primary goal of OS/2 is to 
provide multitasking without reducing 
the performance and response available 
from a single-tasking system. 

Multitasking involves more than the 
ability to effect a “context switch.” It 
needs an effective memory management 
system that protects each program, 
reclaims the memory when no longer 
needed, and manages memory overcom¬ 
mitment. In OS/2, all this needs to be 
accomplished at no extra performance 

The first part of the book traces the 
history of OS/2 through the different 
versions of MS-DOS, outlines the goals 
and compatibility issues faced by the 
system’s designers, and summarizes the 
system’s driving philosophy. The eight- 
page third section contains the author’s 
view of OS/2’s future. 

The second section examines in 
uneven detail how the basic components 
and key concepts are implemented. It 
begins with a chapter on multitasking 
that presents a subtask model where the 
child process inherits much of the par¬ 
ent’s environment. It discusses in great 
detail how this approach is used for per¬ 
forming file I/O. The next chapter 
describes the design of the priority- 
based preemptive scheduler used for 
achieving multitasking. 

One of the key and unique implemen- 
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tatiori techniques in OS/2 is dynamic 
linking. Dynamic links are more than 
system calls. They provide the system 
interface and a high-bandwidth device 
interface that makes the device drivers 
device-independent without the 
associated overhead; they support the 
open architecture nonkernal service 
package; and they allow applications to 
make high-speed calls to a subroutine 
package that can directly manipulate 
the device. 

The other chapters in the second sec¬ 
tion discuss implementation of the clas¬ 
sical operating system elements such as 
the memory management scheme, inter¬ 
process communication, the file system, 
and device drivers. The last chapter in 
this part discusses how the hardware 
constraint of the 80286, namely that it 
can run in either the 8086/8088 emula¬ 
tion mode or the 80286 protect mode 
(and not in both modes), was solved to 
address the downward compatibility 
issue of OS/2. 

Although the book is well written, it 
is not easy to read, especially without a 
good theoretical background in operat¬ 
ing systems principles. The author also 
assumes a systems-level understanding 
of MS-DOS architecture. 

Since the author’s objective is to pro¬ 
vide a broad understanding of the 
implementation strategies used in OS/2, 
the book can serve as a supplementary 
text for a university-level course in 
operating systems to illustrate imple¬ 
mentation of the traditional compo¬ 
nents of multitasking operating 
systems. In addition, the first part pro¬ 
vides an excellent philosophical intro¬ 
duction to the issues involved in the 
development of OS/2. 

Donald D. Chand 

Bentley College 


Local Area Networks and 
their Architectures 

Eduard A. Yakubaitis (Allerton 
Press, New York, 1986^28 
$58.50) 

f The fact that around 80 to 90 percent' 
of all information circulates within the 
organizations and enterprises that 
generate it has prompted the acceptance^ 
S 'NQf local area networks. This 
lyzeil LAN afcfiltegr uiis. iT ai 
software, paying particular attention t 
standards. 

The first three chapters deal with 
definitions and explanatory examples 
and discuss the fundamental architec¬ 


tures and associated technology. The 
author here describes the basic refer¬ 
ence model for OSI networks. 

The author separates LANs into two 
groups: those with information routing 
and those with information selection. 
The first group establishes a precise des¬ 
tination address in the interaction 
between subscribers, while in the second 
group, a destination address receives all 
information but accepts only informa¬ 
tion addressed to itself. This adds an 
interesting perspective to the conven¬ 
tional classification encountered in the 
related literature. Under this arrange¬ 
ment, for example, random-access and 
token-passing networks belong to the 
second type of network. 

Recent developments in networks 
with information routing—the oldest 
kind of LANs—have made them inex¬ 
pensive, reliable, and able to admit 
voice and data processing simultane¬ 
ously. Single- and multiple-node private 
automatic branch exchanges are consid¬ 
ered part of this group. 

Chapter 4 covers international OSI 
standards for the application, presenta¬ 
tion, session, data-link, and physical 
layers. (As the author correctly states, 
the services offered by the transport and 
data-link layers usually absorb the net¬ 
work layer.) The discussion is based on 
the European ECMA standard; equiva¬ 
lent IEEE 802 standards are only briefly 
mentioned. Finally, the book gives a 
short account of recent trends incor¬ 
porating these protocols into hardware 
to reduce complexity. 

The author’s analysis leans towards 
European standards and hardware 
implementations, but this does not 
affect the book’s usefulness as a refer¬ 
ence handbook, since manufacturers 
tend to comply with international stan¬ 
dards. Besides, the author provides 
numerous examples from systems 
implemented in the United States. 

The author provides little network 
performance analysis. However, Chap¬ 
ters 5 and 6 give some insight into 
which kind of LAN might be best for a 
specific computational environment. 
The book’s lack of a specific example 
of a session in a LAN environment— 
from opening to closing—is a draw¬ 
back. The information can be deduced 
from the overall functional analysis of 
the layers, but I would have liked 
roundup examples, such as in A.S. 
Tanenbaum’s Computer Networks 
(Prentice Hall, 1981). The author also 
should have explained the book’s struc¬ 
ture to guide the reader to specific areas 
of interest. The table of contents cer¬ 
tainly does not provide enough infor¬ 
mation for this purpose. 

Overall, however, the author fulfilled 


his purpose of providing a LAN refer¬ 
ence book with special emphasis on the 
upper OSI layers. Users concerned with 
the software approach to these net¬ 
works may find this book particularly 
useful. 

Walter Grote 
Polytechnic University 


Explorations in Parallel 
Distributed Processing: 

A Handbook of Models, 
Programs, and Exercises 

James L. McClelland and David E. 

Rumelhart (MIT Press, Cambridge, 

Mass., 1988, 344 pp. (2 5/ 4 -inch 

floppy discs included), $27.50) 

Volumes I and II of Parallel Dis¬ 
tributed Processing: Explorations in the 
Microstructure of Cognition by McClel¬ 
land, Rumelhart, and the PDP 
Research Group have become a bible in 
neural-network research. No other text 
covers such a wide range of theoretical 
and application-oriented approaches to 
connectionist modeling. The papers col¬ 
lected in these volumes range from for¬ 
mal analysis of the common 
representations and learning algorithms 
in connectionist models to applications 
of the models to problems in cognitive 
psychology and neuroscience. 

Until now, however, it has been 
extremely difficult to explore the 
.dynamics of these systems. No general- 
purpose, low-cost connectionist simula¬ 
tors are widely available yet. The com¬ 
mercial systems released to date have all 
been of high cost, low quality, or both. 
P3 and the Rochester simulator, two 
noncommercial simulation systems, run 
only on high-end workstations and are 
not yet of commercial quality. Pro¬ 
gramming connectionist models using 
conventional programming languages is 
very difficult and time consuming. 

This third book in the series, and the 
accompanying software, allow those 
readers without the time or ability to 
create their own simulators to explore 
the dynamics of the models described in 
the first two volumes and to create their 
own connectionist models. This hand¬ 
book will likely have the same effect on 
the numbers and productivity of people 
doing research on connectionist models 
that the first Fortran compilers had on 
the field of scientific programming. 

The first chapters provide a general 
overview of connectionist modeling and 
introduce the simulators. Since all of 


118 


COMPUTER 
















the simulators have a similar interface, 
the reader can fully transfer the expert¬ 
ise developed with the simple interactive 
activation and competition models in 
Chapter 2 to the models in later 
chapters. 

Chapter 3 describes simulations of 
the Boltzmann machine and other con¬ 
straint satisfaction models. Though the 
handbook frequently refers to the 
essays in the previous volumes on which 
the simulations are based, this book is 
self-contained and summarizes the 
original articles where necessary. Most 
mathematical results are presented with¬ 
out derivations, and the many figures 
and tables help the reader understand 
the operations of the models without 
unnecessary complications. 

Chapters 4 and 5 cover learning 
algorithms. Hebbian learning, the delta 
rule, and back-propagation are all dis¬ 
cussed in detail, with many exercises 
illustrating the power and limitations of 
the various algorithms. The exercises 
are relevant and well specified, making 
hands-on use of the simulators an easy 
and enjoyable task. An appendix pro¬ 
vides answers to the questions posed in 
the exercises. 

Some exercises suggest that the user 
create new networks—a relatively 
straightforward process. The network 
architecture is specified in a text file 
that must be edited outside the simula¬ 
tors. Pattern files and weight files can 
be read or written at any time, and both 
can be edited from within the simula¬ 
tors using your favorite text editor. 

Creating a template file (the file that 
defines how the network will appear on 
the screen) is more difficult; here the 
lack of a graphical interface becomes 
most noticeable. The template file for¬ 
mat is well specified, however, and a lit¬ 
tle practice makes templates much 
easier to modify. The linked and con¬ 
strained weights features in the back- 
propagation simulator contain the only 
bugs I discovered in the simulators. 

These features are not used in any of 
the exercises, and a fix has been posted 
on Bitnet and will undoubtedly be avail¬ 
able from the publisher. 

Chapter 6 covers auto-associators 
and competitive learning. These models 
form their own categories by detecting 
regularities in the input patterns, so 
they do not require a “teacher” to cor¬ 
rect their mistakes as do the other learn¬ 
ing algorithms. Though the operation 
of these networks is inherently more 
complex than that of the other types, 
chaotic operation is not a problem if the 
exercises are followed. Throughout the 
text, samples written in a C-like pseudo¬ 
code illustrate the implementation of 
some of the key routines in the simula¬ 


tors. This frequently clarifies the 
model’s operation and provides land¬ 
marks if a more detailed look at the 
source code is necessary. The disks 
include all of the source code, which is 
cleanly written and moderately well 
documented. 

The last chapter explains the interac¬ 
tive activation model of word percep¬ 
tion. It briefly discusses the 
psychological phenomena the model is 
based on and thoroughly explains the 
model’s operation. The model includes 
a large number of exercises, since a 
large number of parameters can be var¬ 
ied. Many of these exercises reproduce 
experiments performed by other 
researchers in psychology, further 
demonstrating the power of the connec- 
tionist approach. 

The programs require an IBM PC, 
XT, AT, or compatible machine. A 
floating-point coprocessor is recom¬ 
mended but is not required. Most of the 
simulators ran well on a two-floppy 


This handbook will likely 
have a large following in 
the near future. 


machine with only 256K of memory. 
Readers can gain more performance for 
larger experiments than those in the 
handbook by uploading the code from a 
PC to any Unix system. A Make file is 
supplied that builds all of the simulators 
and the two support programs used to 
make character-based graphs of the 
data produced by the simulators. The 
Make file and the resulting programs 
worked properly on a Sequent Balance 
multiple-processor computer running 
Dynix and on Sun workstations running 
4.2 or 4.3 BSD. 

No support is provided for the soft¬ 
ware (not even a phone number or 
address), but this should not be a prob¬ 
lem given its robustness. This handbook 
will likely have a large following in the 
near future, so electronic news and 
bulletin board systems may provide a 
means of support. 

Overall, this high-quality, low-cost 
package is the recommended starting 
place for anyone interested in learning 
about neural networks or connectionist 
models. The simulators are fast, power¬ 
ful, and easily expandable. Though 
their displays and graphics are 
character-based, they run on widely 
available hardware and should prove 
easy to upgrade in the future. 

Scott M. Raney 

University of Colorado, Boulder 


NEW LITERATURE 


Job-hunting guide. Peterson’s Guides 
has announced it will publish the 10th 
edition of Peterson’s Engineering, 
Science, and Computer Jobs 1989 in 
September (ISBN 0-87866-692-3, 700 
pp., paperback, $19.95; ISBN 
0-87866-828-4, 700 pp., hardcover, 
$34.95). The book is designed to help 
recent graduates and experienced job¬ 
hunters identify and contact employers. 

This updated edition profiles over 
1,100 manufacturing, research, consult¬ 
ing, and government organizations. 
Each profile includes entry-level open¬ 
ings and starting locations, opportuni¬ 
ties for experienced personnel, company 
products and services, degree majors 
sought, doctoral-level opportunities, 
and contacts for more information. 

Contact Peterson’s Guides, 166 Bunn 
Drive, P.O. Box 2123, Princeton, NJ 
08543-2123. 

Federal software market. Input, a 
market research and consulting firm, 
has issued a new report, Federal Soft¬ 
ware and Related Services Market 
1987-1992, examining the federal soft¬ 
ware market and the potential for 
greater use of off-the-shelf software by 
federal agencies. The report estimates 
that government demand for software 
and related services will increase 12 per¬ 
cent by 1992, from $1.7 billion to $3 
billion. Contact Input, 1280 Villa St., 
Mountain View, CA 94041-1194; phone 
(415) 961-3300. 

Testability guidelines. Logical Solu¬ 
tions Technology has reprinted Design 
to Test by Jon Turino and H. Frank 
Binnendyk (226 pp., $150). The book’s 
10 chapters include guidelines for digi¬ 
tal and analog devices, boards, and sys¬ 
tems, LSI/VLSI components, mechanical 
software, and documentation. The 
book also has been translated into 
French. Contact Tina Nuss, Logical 
Solutions Technology, 310 W. Hamil¬ 
ton Ave., Suite 101, Campbell, CA 
95008; phone (408) 374-3650. 

Digital signal processing report. Frost 
& Sullivan has released a 331-page 
report on The Digital Signal Processing 
Products Market in the US (No. A1898, 
$2,250). The report splits the market 
into two main categories: the digital sig¬ 
nal processors themselves (led by single¬ 
chip DSPs) and data conversion 
products (including analog-to-digital 
and digital-to-analog converters, mul¬ 
tiplexers, and sample and hold circuits). 
Contact Customer Service, Frost & Sul¬ 
livan, 106 Fulton St., New York 10038; 
phone (212) 233-1080. 
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June 19-21, 1989 

Deauville, France 

TOPICS 


IWDM is an international conference dedicated to research on high 
performances for database systems, knowledge base and text base systems, 
and to the corresponding architecture and hardware aspects. Its main topics 
include, but are not limited to: 

Database Machines 

VLSI implementation 

Sorters 

Parallel Architectures for Databases 
Distributed Architectures 

Main Memory Database Systems 

Knowledge Base Machines 

Prolog Machines 

Information Retrieval 

High Throughput Transactions 
Performance Evaluation and 
Measures 


PAPERS SUBMISSION 

Six copies of a manuscript limited to 5000 words should be mailed by 
November 1,1988, to the appropriate Program Committee Chairman 

from United States 

from other countries 

Haran Boral 

Pascal Faudemay 

MCC 
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75252 Paris Cedex 05, France 

boral @ mcc.com 

mevax! inria! litp! faudemay 


IMPORTANT DATES 

Paper Submission Deadline: 

November 1, 1988 

Notification of Acceptance: 

February 16, 1989 

Camera Ready Copies Due: 

March 31, 1989 


GREETINGS 

The workshop site is a famous sea-side resort near Paris, with a beautiful sand 
beach and a usually warm weather in June. Early registration for IWDM will be 
possible until May 10th 1989. Further information: please write to P.Faudemay, 
or call Th.Bricheteau secretariat, tel: (33) 1 39 63 56 00. We hope that you will 
take this occasion to visit France and attend high level lectures. 
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